Manually written business objects or using DAL objects?

Question

Suppose you have three tiers (with namespaces):

• User interface (App.UI) - calls business layer processes and communicates using objects
• Business layer (App.Core) - orchestrates processes and uses DAL layer using objects
• DAL (App.Data) - directly manipulates store and persists objects

Let's say that you have User table and thus reflected in your DAL layer in App.Data.User and probably also App.Data.Users.

There's a view in your UI that displays application users.

To really have a separated (layered) application, you should also have App.Core.User and App.Core.Users that you'll probably have to create manually.

The best solution (by my opinion) would of course be: There should be a fourth layer Business Objects (App.Objects) with classes App.Objects.User and App.Objects.Users. These POCOs would be shared among all layers. Business layer would only be allowed to use DAL, UI will only be allowed to use BL, but all of them would use App.Objects for common object model.

Asp.net MVC templates imply on using DAL objects directly on Views, LINQ 2 Entites also don't create any POCOs per se...

So when using any automated code generation are we supposed to use DAL objects or manually hard code our shared POCOs? First part seems as an easy way out but doesn't separate DAL from UI (and may have security and scalability concerns later), the second one is prone to errors and very tedious with medium size database.

What would you suggest?

Answer 1

What you call a App.Objects is basically your Domain Model and it is logical to be shared between all layers to pass the data around but you need to decide if this model will be anemic or active.