Printable View
Just wondering if you guys prefer starting your applications from a form or from a non-UI class?
One of the methods of developing applications is to keep the UI seperate from the business rules and actual code. I think this would lean toward starting from a class and having the class control the UI.
Any thoughts?
In one of my applications I used an Application class, that acted as the entry point to my application. For each form, I had an associated class that handled all of the business logic.
Do you have any recommendations on any books discussing Design Patterns?
Maybe I do things backwards but I seem to have the UI control the class or at least interact more with it. Since the class(es) are constant no matter the UI and the UI could be different. I usually start from a form unless I have some kind of decisions to make regarding alternate loading then I start from a Sub Main.
I have also done that in the past (starting the application from a form). But I am beginning to think that it might be better to start it from a non-UI class so that the logic is seperated from the UI more.
Then you could (in theory) change the UI with no effect on the logic classes. But this would mean starting an application from a DLL (Business Logic) and call your EXE (UI) - and I don't think you can do that.
Check my post onthis thread for some books.Quote:
Originally posted by Lethal
Do you have any recommendations on any books discussing Design Patterns?
The .Net design patterns book does have a strange implementation of the MVC pattern. It suggests putting GUI components in the Controller, which in my experiance goes against the principles of MVC.
As .NET is very GUI driven I tend to instantiate the GUI which inturn creates its own controller object to handle the communication between Data Model and GUI. This way I can completely replace my GUI (within reason!) with minimum impact, if any, on the business code.
There is, of course, no right way to do this, but it works very well in my company. I'd be interested to here more opinions...
sorry my company firewall won't let me edit posts!
I'd like to add to the above....
The GUI creates the controller by raising an event
This way, the controller has a direct link to the data model and Gui (via an interface) and the GUI does not know about the controller directly and communicates with it via events.
This is a hard topic to discuss without trying it really!
:(
Could you post a small sample. Also, say you have an 'Add Employee' screen where 5 out of the ten fields are required. Should you handle this validation in the presentation tier or business tier?
I need a book...:D
For me, I would handle the validation of the data at the presentation level, then send only verified data on to the business tier.Quote:
Originally posted by Lethal
Could you post a small sample. Also, say you have an 'Add Employee' screen where 5 out of the ten fields are required. Should you handle this validation in the presentation tier or business tier?
I need a book...:D
Reason I believe this:
Your objects in the business tier should also check the data for errors, but it should 'expect' clean data from the presentation tier. Only simple checks should be done to ensure that the data is the correct format. These checks start with the arguments accepted, the properties and go on from there.
I don't know if my way is right, but it seems to work for me. The reason I like it this way the most though is because if I decide I want to change the presentation layer, and how it collects data, then all my validation work is done there, and not spread out any further. I just need to format the data the way the business tier expects, and all is good.
I agree with you, hellswraith, thats how I do it too, which doesn't mean that we are both wrong but ignorance is bliss.
I think especially since you might change the presentation layer, from windows to web, or to a different language. Also validation usually means having to interact with the user and have them fix something which would or should be done at the presentation layer anyway.
It gets complicated when you need your business rule to validate the data though. Then you would either have to put that business rule into the UI, or notify the UI layer of the validity results in order to display a message or error provider.
I keep going back and forth on how to precisely divide the two, and what should be handled where, and by what means.
But in the presentation layer, you can pass the data to the business layer by calling a validating routine. It returns the validated data and/or the error. Your presentation layer then takes that, presents it to the user if needs to get them to change it, if not, the presentation layer then proceeds as normal passing the data to the business layer.Quote:
Originally posted by VBCrazyCoder
It gets complicated when you need your business rule to validate the data though. Then you would either have to put that business rule into the UI, or notify the UI layer of the validity results in order to display a message or error provider.
I keep going back and forth on how to precisely divide the two, and what should be handled where, and by what means.
You cross the lines a little but, you still have the actual calls for the validation in the presentation layer. The business objects handle it, but they just return whether or not it is good.
As a rule I would normally validate 'input' data on the presentation tier. i.e. validation specific to the GUI controls on the form, like only accepting numeric characters or only allowing a certain number of characters in a text box etc.
I still validate all data passed to the business layer, even if it appears that I am duplicating some effort. This is because if my GUI was replaced or updated, (in my experiance we replaced all datagrids in our product with a better 3rd party one), and the person updating the GUI failed to put adequate validation in, then my business layer would not suffer any adverse effects.