I am working on a project where the lead developer is advocating removing all of the properties from the business layer and making it 'transparent' (using it solely as a means of calling data layer methods). Instead of binding the UI controls to the business layer, he is binding the controls directly to the entity objects themselves. It seems he has taken most of the 'support methods' and lazy-load properties from the business layer and moved them to the entity layer. As a result the business layer's only purpose is to call the DAL methods and return entity objects to the UI controls.

Is there anything lost or gained by this approach, as compared to limiting the entity objects to strictly private fields and properties?

I guess I'm not understanding the question exactly. Can you provide an example of any kind to illustrate what you mean?

In the book we bind UI controls directly to business objects. These business objects have methods and their properties are loaded through a process of converting entity objects into a business object.

How is this different from a framework where the business objects contain only methods (no properties) and instead of converting the entity objects into business objects, these business methods just pass the entity objects themselves directly to the UI controls instead of first converting them to business objects?

Okay, I kind of see what you mean now. I think. :D

I have seen apps built this way, where the UI reaches directly into the DAL and uses the entities from there. It's a valid approach, but in my opinion, you lose a lot of the benefits of the n-tier architecture that way.

To a lot of folks, I suppose it seems repetitive to build entities to wrap the database fields, then build business objects that in large part merely represent those entities. But part of the objective of n-tier is the isolation of layers. In other words, the UI only reaches into the BLL, the BLL only reaches into the DAL, and the DAL only reaches into the DB.

Letting the UI "jump over" the BLL into the DAL, to me, partly defeats the purpose of having a BLL in the first place.

Of course, this is only my opinion. Other folks may differ.

Anyone else have an opinion on this? I'm curious what you guys think of the architecture pinch is asking about.

I like the general idea, but I'm a little more radical in my approach. I never like empty wrappers so I don't see a need for a BLL in this case. We need lazy loading but exactly where this occurs is based on the model. Having a stronger set of entity classes is perhaps more consistant with the ORM approach.

The lighter Entity class model is a better fit for SOA. SOA is built on delegation so you don't want to pass heavy classes between services.

Neither ORM nor SOA is friendly to a pure nTier model, which is why nTier is losing a lot of support in recent years. ORM blurs the distinction between BLL and DAL, and SOA is incompatible with nTier because you never lock want to lock yourself down in a vertical hierarchy - it has to be more flat with various services all willing to help each other. You can can have a Data Access Service, and many Business services that consume the Data Access Service, so that seems like nTier. But you may also have more than 1 data service, and the business services may have to work with various data services. So the model becomes flattened. Many services all willing to work together. But SOA is tightly interface driven and you have strict boundaries, so you do have the separation which is what nTier really wanted to give you.

Disclaimer: some people maintain that SOA is actually one possible implementation of nTier, rather than being something different. They are right. But when you say "nTier" it brings certain things to your mind that are not compatible with SOA so I just keep things simple in order to avoid confusion.

As a test of separation we could add a different front-end that is compatible with the same back-end. A WPF Browser Application could bring a new and exciting GUI for users to interact with, while still keeping the same "classic" browser GUI for users who can't support WPF - a little Silverlight will keep them happy!