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 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.