Approach for n-tier CRUD applications in .NET

Question

Here’s a really really super-basic question.

Say I wanted to build – today – an enterprise CRUD application in .NET that had an n-tier architecture. What data access approach should I use? I want interoperability, so DataSets are out (and I suppose it’s not 2003 anymore, either). Likewise, .NET RIA Services’ advertised method of exposing its functions, via an additional service, to non-Silverlight clients, doesn’t seem very convincing for update operations. I’ve sort of been able to cobble together something with Entity Framework, which doesn’t have n-tier support OOB and so required lots of weird reflection-type stuff to simulate the semblance of optimistic concurrency (the example in MSDN Magazine doesn’t look like it supports optimistic concurrency. I hear this is improved in EF4, but I’m a little bit skeptical and it’s not really available yet besides in CTP).

So, what can people actually do on their projects for enterprise CRUD with update-checked optimistic concurrency? DataSets? DIY with DTOs and Lord knows how much work involved? And how does that work with bound data? Say I have a collection bound to a DataGrid, do I need to listen to CollectionChanged for changes? Do I need to keep stacks of changes so I can compare PKs if there’s an undo? It seems nightmarish.

And, secondarily, what if update checking for optimistic concurrency weren’t a hard requirement? What then?

Answer 1

First off, if you plan to move to VS2010 and .NET 4.0 in the future, I highly recommend looking into EF v4.0. It has improved DRAMATICALLY since EF v1.0 was released, and is, in my opinion, a strong contender against the likes of nHibernate and friends. EF is the central player in a lot of Microsofts future data initiatives as well, so it can't really be ignored as easily as it used to be. It, or any of the .NET 4.0 higher level frameworks that depend on it, should serve your CRUD needs well.

That aside, I would just make sure that a simple CRUD approach is the best fit from a business perspective. CRUD makes a ton of sense from a technical perspective, and in smaller applications, it is usually the right choice. But you used the term 'enterprise', so I am curious if your application has a broader scope than the simplicity CRUD serves well.

Anything beyond your small-scale company with 20-50 or so employees total, and I would look into Domain Driven Design (DDD) and SOA. If you need things like concurrency management and things like that, the principals that drive DDD should serve you well. SOA is generally useful for extremely large projects where you have many development teams concurrently working on multiple projects that need to interact with each other. It may be overkill for your needs, but there are some good principals that may still help.