The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Separation of UI and business logic....???!!!

This certainly is not a new topic or new concept. However, in the project I will be working on, there is now a big controversy over whether or not using XXX as the business framework, which fundamentally boils down to certain people's uncomfortability with even having a middle layer sitting in between UI and database.

Having worked on a big project that used a business layer, I feel some what a loner in the situation, it seems that I am the few who's comfortable with loosely coupled design and particularly having a data objects layer. It certainly disturbs me listening people belittling the N-tier design pattern simply out of ignorance.


However, I would love to make stronger arguments as to why we should have such a layer, yet my limitation is that I have worked on projects that used that layer from the beginning and I have NOT worked on projects that fail without it.

Can any great and experienced minds out there help me with a clue here? Why should we have a business data layer? Is it really that much helpful? Pros? Cons?

thanks a bunch!

Monday, November 06, 2006
 
 
It's hard to argue because the costs are often high, immediate and concrete whereas the benefits usually can't be measured until long after the fact. For many smaller and internal-type systems the separation probably isn't appropriate anyway.
Greg Send private email
Monday, November 06, 2006
 
 
Martin Fowler's Patterns of Enterprise Architecture has some good discussion on when a domain layer is warranted or when a simpler approach will do.
Mike S. Send private email
Monday, November 06, 2006
 
 
Ask them what they would need to change to change the app to be web-based.  Or to support WPF.
xampl
Monday, November 06, 2006
 
 
+1 to Greg, Mike and xampl.

From a purely abstract perspective, it makes a lot of sense to separate them. There may be practical, business reasons not to do so, particularly time, budget, application complexity and comfort level.
TheDavid
Monday, November 06, 2006
 
 
If you don't separate then cleanly then you essentially get a spaghetti code.

This means that there isn’t a specific place in the architecture where the user data entry is validated and where the state of the UI is determined. Without this separation different developers will validate in different places (in the events or in a separate method, for example). The UI state also tends to be evaluated in an ad-hoc manner - a testing nightmare waiting to happen.

A great benefit of having one is that some middle tier frameworks provide a very rich data binding experience thus saving a reasonable amount of code (the CSLA comes to mind).  So, in fact you will save time and code if you create a middle tier with just the right “thickness” for your project.
JSD Send private email
Wednesday, November 08, 2006
 
 
It is more expensive? I wonder why. I'm talking web stuff here, I don't know about desktop stuff. But I can have a framework up in 5 minutes after I checkout from CVS, create a couple of tables, modify the config and write a sample page. I can then create click-through mockups in no time at all. Mind you I'm doing LAMP with PHP. It woudl be the same if Perl. I guess one could do the same with Tomcat and JBOSS.
curdDeveloper
Wednesday, November 08, 2006
 
 
"Martin Fowler's Patterns of Enterprise Architecture" - strongly agree!

Force feed them to read this book. If they don't "get it", then either you or they need to go.
hoser
Wednesday, November 08, 2006
 
 
Domain Driven Design by Evans (an excellent book that I strongly recommend you read after Fowler) suggests that the "smart UI" approach is valid if all the following conditions:

1) The client is almost exclusively database CRUD actions,
2) Domain logic is limited or nonexistant,
3) The team doesn't have domain modelling experience.

If the above are all the case, then you should use whatever codegen/drag&drop/table designer/databinding stuff you can. You'll save a ton of time.

If any of the above are not true, you should go for the tree-tier separation.
Chris Tavares Send private email
Wednesday, November 08, 2006
 
 
Those are wise words. Nobody thinks that #2 describes their system, though.
Greg Send private email
Wednesday, November 08, 2006
 
 
Thank you so much guys for all the comments and pointers.

I really should've thought hard on these myself. All the things you guys mentioned are important and should be considered within our team because we can beat so hard on an ORM framework without going anywhere and what we really should do is to challenge the basics. What's the project's need? business' need?

Thursday, November 09, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz