Wednesday, September 26, 2007

Business and Data Layer Architectures

Strongly Typed DataSets in .NET 2.0 do many things very well but they fall short in other places. For a new project I have been researching alternative approaches for structuring the model, logic, and data access projects to allow for easy customisation and good testing.

Firstly, there are some features about DataSets that are very useful and would need to exist in any alternative I consider:

  • Collection filtering and sorting by any properties.
  • Collection and item change notification.
  • IEditableObject support (ie BeginEdit, EndEdit, CancelEdit).
  • Excellent encapsulation of SQL commands.

There is also the limitations of DataSets that should not exist in the alternative I choose:

  • Computed values too complex for DataColumn.Expression cannot be bound to.
  • AllowDBNull and MaxLength violations cause immediate exceptions.
  • Restrictive relationship between model and underlying database structure.
  • Does not utilise Nullable<T> to support columns that allow DBNull.
  • Change notification events cannot be completely silenced.

So far I have briefly investigated CSLA, SubSonic, NHibernate, and some existing applications both real (DotNetKicks) and example (MS Pet Shop), and found that they are all very similar in many ways. Rather than commit myself to a particular framework that may have it's own set of issues I have decided to hand code my own solution to the business and data layering problem.

Others have expressed concerns about going with a third party framework and to a point I agree, but I'm not totally sold either way yet.

I intend to watch my own code evolve as I solve the difficulties associated with the task and refactor my work into common classes. I expect that my code will begin to look much like one of the existing frameworks (although that may be biased by what I've already seen) and perhaps I will end up switching to the solution that most closely matches my own.

The last thing we need is yet another framework.

Monday, October 15, 2007 11:20:02 PM (Cen. Australia Standard Time, UTC+09:30)
Jason,

To be honest, I'm surprised that you wouldn't have gone with a pre-built packages for your data layer. A friend of mine, Brendan (http://www.kowitz.net) has recently been playing pretty heavily with NHibernate and by all accounts, he can't believe he hasn't and wasn't using it much sooner. During the development phase, he commented continuously on its amazing ability to facilitate rapid prototyping but even once that was largely done; he had a wildly configurable data provider that does an enormous amount 'for free'.

Out of interest, what made you not go with one of the existing frameworks such as NHibernate?

Al.
Tuesday, October 16, 2007 7:36:49 AM (Cen. Australia Standard Time, UTC+09:30)
Hi Alistair,

I too have heard several people praise the various frameworks available but I've also felt that some of them are overkill:
http://notgartner.wordpress.com/2007/09/25/frameworks-frameworks-frameworks/

Additionally, I try to minimise external dependencies wherever possible and after being bitten by Strongly-Typed DataSet I am wary of signing up with another framework that may have it's own set of unavoidable limitations.

I have since made good progress on my own solution and I am very happy with my choice. I am very comfortable with SQL (perhaps even proficient) and like to get my hands dirty with data normalization and custom queries. My main concern was finding an approach to get data from the database into object without needing strings to identify tables and columns and also to have business objects with design-time binding, change notification, and support for the Error Provider.

I will post in detail about my results soon.
Tuesday, October 16, 2007 2:12:49 PM (Cen. Australia Standard Time, UTC+09:30)
Jason,

I do take the points that Mitch is making, however to say that System.Data is all you'll need for data access is a bit rich in my opinion. Maybe everything I've ever seen in .NET is horribly skewed but everyone ends up writing some sort of a data layer for their chosen platform, if for no other reason than to abstract it away.

After talking to Brendan and seeing what he has been buidling on top of NHibernate, I look at it as a very flexible persistence engine. I won't call it a pure data layer, as if it were to simply use the System.Data namespace because it is so much more than that - but it is pretty impressive. Maybe Brendan will reply with some comments about his experience using NHibernate and what his world view of it is.

Al.
Comments are closed.