Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Question about accessing form objects...
Message
General information
Forum:
ASP.NET
Category:
Forms
Miscellaneous
Thread ID:
00736154
Message ID:
00736294
Views:
14
Hi Kevin,

What you want to avoid is mixing the UI into the business logic. If you pass the Form class to the business tier like you want to do, you are doing the same thing as putting the business logic inside the UI. If you change the form to be a web page, your logic will break. This is what you want to avoid.

What I recommend is to expose methods in your business logic that you call in the UI which return the information you need for verification, formatting, or whatever else you need in the business logic. Instead of passing the control itself, or work with the control in the business tier, you pass the contents of what is in the control that the method would need to be able to return the result. Then the control would need to use the result to display it correctly.

The main question you always want to ask is "If I change my UI to something else would my business logic method break?". If the answer is yes, then change the method to be more generic. This process can be more difficult to program and can at times need a "creative" mind but it will benefit you greatly as the needs of your application expand in the future.

>Cathi/David...
>
>Thanks for the answer. I was originally using 'form'. When I changed the parameter on the receiving end to the name of the form class, that worked, and gives me what I was looking for?
>
>A follow-up question, based on David's response. This approach works so long as the control modifier is either public or internal. If the controls are private/protected, then obviously that won't work.
>
>I understand why, in principle, the use of public/internal modifiers is generally discouraged...however, this seems to be the only way for a 'rules class' to have access to the controls on a form.
>
>Main reason I'm looking to do this, ironically, is to avoid another 'no-no'...significant amounts of business logic code in the same source file as the UI.
>
>The types of things I want to do in this 'rules' class:
>
> - Define grid contents
> - Reading contents of a custom QBE screen and building a WHERE clause
> - Defining bindings for controls
> - Other miscellaneous operations that require examining contents of controls
>
>
>Any additional thoughts?
>
>Thanks,
>Kevin
-----------------------------------------

Cathi Gero, CPA
Prenia Software & Consulting Services
Microsoft C# / .NET MVP
Mere Mortals for .NET MVP
cgero@prenia.com
www.prenia.com
Weblog: blogs.prenia.com/cathi
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform