Business components: when to introduce them

Question

I am performing a code review (VS2008/.NET 3.5). The development team has created several data access components in a DAC assembly.

I encountered a business proces assembly where every DAC is wrapped with a business component with no additional value or code.

Is this a right premature architectual step ? Just to be prepared for something going to happen like: caching or validation or transactions? All these last mentioned topics are not the case right now but could happen in the future.

I made a comment in the review that introducing this kind of architectual preparations is bloating the code-base. So try to introduce it only when it is really needed.

What are your experiences about this issue?

Answer 1

My vote is to always have business objects, and always write your applications in terms of them. This makes the application layer data access agnostic, and improves your flexibility overall. It does take a little more up-front work, but the dividends for any long-living application are more than worth it.

Answer 2

Kudos for taking a stand. My first mistake as an architect was to implement all the layers on my diagram before a single line of functional code was written. It is good to plan for your layers (on a diagram), but they should only be implemented when needed.

When needed is usually:

• Separating logic over physical tiers
• Introducing additional behavior that logically belongs in a separate layer
• Forcing indirection in order to support a pattern (as long as the pattern isn't a self-justifying abuse of the architecture).

That being said, even if you don't implement the layers at the beginning, you still need to be careful to avoid tight coupling between layers. That way when you do need to create the layer, you don't have to rewrite a bunch of code.

Answer 3

I agree that it may seem like overkill to have an "empty" business layer -- but my question is, if the business classes are essentially empty wrappers for the DAL classes, where is the business logic in the app being coded? In these cases, I often see it spread throughout the UI and DAL code and/or in the database/stored procedures, which defeats the entire purpose of having a business layer in the first place.

If you are going to have a business layer, then it should encapsulate as much of the business logic as possible, including validation and various methods of persistence. If you essentially let the business layer be a bunch of "dumb" Data Transfer Objects, it is not providing any value and you should probably consider developing your architecture without one.