Object Construction at Client or Business Layer?

Question

Something I've noticed from looking at multiple .NET starter kits is that business object construction is often handled at the client level. Then, the business object is passed to the business layer for manipulation, serialization to the database, etc. Shouldn't this code be abstracted to the business layer, so that the client only needs to pass the necessary data? Is there any advantage to having a business layer with CRUD abstractions that only accept objects as arguments?

Answer 1

I would typically do this type of work in a Service or Data Access Layer. That is, for smaller project I have my data access layer return my domain objects. For larger projects I would use a service layer to handle complex object construction and invocation of business logic.

Answer 2

I agree with you, that interaction with the business layer should be kept as simple as possible, with complex types and other complexity hidden, or else what is the point. At the point where your UI and Business objects are wired up, there should be as close to 0 complexity as possible.

I can imagine scenerios where the construction of relatively complex types at that point would be legitimate. The smaller a site is, the more likely that < 3 tiers can actually be better than strict 3 tier. So to be open minded about the starter kits your are seeing: maybe the scope is so small that strict separation of concerns would be overkill, and their approach might well be appropriate for the situation. Or, what they're doing is so complex that this is the best way to handle it. The more complex the wire-up or integration, or if there is a plug-in model or something, a seemingly overly-complex type can actually be what ensures a consistent flexible interface. Sometimes a little complexity in one place saves you a ton of complexity somewhere else. But more often this is not the case. My guess is that what you see as bad really is . . . bad.

1. Many microsoft quick-start demos and templates have really bad architecture. The web-forms model itself does not lend itself to good separation of concerns. You'll see a lot of official examples that are spaghetti code nightmares. Business, DB, and user interface living together is horrible harmony.
2. If you're talking about 3rd party SDKs: many of these require complex types passed to the business objects because they were ported from C++ but never really revised to be object oriented. A couple times I've had to make some insane types to pass to some imaging software objects, where logically it only needed two simple value parameters.