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.

Communication between layers

Hi there guys, just wondering if anyone can clear this up.  I understand that you use layer seperation with UI, business logic and Data access but all of these have to communicate.  For example, if you want to display a list of customers these need to be passed back to the presentation layer to display. 

I'm assuming you get the DAL to generate a list of objects in a list which the presentation layer components such as datagrids in can use to display the information. is this correct ???

seems a lot of passing around ! presentation layer requests
a list of objects from the business layer, the business
layer calls the DAL, this gets the list and the business layer passes it back ?

Many thanks
andrew deakins Send private email
Saturday, September 17, 2005
That's pretty much it.

The goal of the layered architecture is separation of concerns. This way, when your database schema changes, you only need to change the DAL, not the entire system. If your business rules change, you only need to change the business layer. If your UI changes, you only change the presentation layer.

It does work. And you'd have to "pass around" this stuff even if the presentation went straight to the database somehow, so it's not as bad as you might think.
Chris Tavares Send private email
Saturday, September 17, 2005
The layers are also ment to do something.
The business layer should be supporting questions the interface needs to ask, like
* is the user allowed to see this info
* can they modify this record at the moment
and marshelling appropriate calls to it's resources like the data access layer, or config...

Sunday, September 18, 2005
For small one off projects (<10 kloc), separating things into layers might be overkill... But for projects that might get big or is already big, the cost of passing around objects is negligible compared to maintenance cost... Just make sure the performance of the critical part of your software is still acceptable...
badaiaqrandista Send private email
Sunday, September 18, 2005
Microsoft actually has a pretty good series over on the MSDN Patterns and Practices section. There can actually be even more layers than what you have mentioned. For example, I like to use a User Process layer to hold all of the workflows and the state machine. For simple CRUD applications this is overkill. But for applications that have a more complex workflow it can be very valuable. Most people end up putting this kind of flow directly into the UI which makes changing the UI more difficult.

Anyway, the following link has some decent reading. Be sure to check out the whole series.
Monday, September 19, 2005
Maybe you find a way to pass by an interator rather than a list.
Dino Send private email
Monday, September 19, 2005
Using an interator is the preferred choice.  It not only abstracts the UI concerns from the data access concerns; but, it also abstracts the implementation in the DAL from the UI layer.  i.e. the UI layer now does not need to know how the DAL implemented a container--only that it can iterate that container.
Peter Ritchie Send private email
Saturday, September 24, 2005

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

Other recent topics Other recent topics
Powered by FogBugz