Mythical Man Moth

Recently I’ve been working on a project where we use a certain kind of architecture. Now I’m no architecture snob, but I’ve been struggling to come to terms with this specific architecture(which from here on will be referred to as NOA) and here’s why.

For regular readers of this blog, it’ll come as no surprise that I’m a bit of a CSLA fanboy; but I do prefer the Object Orientated/Business Object approach to tackling development challenges. With this architecture there is no separation between the data access layer and the business layer. i.e. business rules and custom logic resides in the dataset’s code behind. A few things irks me about using datasets and the NOA approach:

• Changes to the database can not be automatically generated, the datasets need to be manually refreshed/configured.
• NOA does not lend itself well towards code generation
• Business Rules can not be separated to another layer easily
• When building program logic code, it is near impossible to access object level properties. i.e. Have to work with dataset row, rather than object.

I’m nowhere perfect, nor can ever know nearly enough IT kung fu, so would love to hear a few opinions about this approach or any examples where it was used successfully. Also, does anyone know if this is an accepted Microsoft pattern?