Approach for n-tier CRUD applications in .NET
Here's a really really super basic question.
Let's say I wanted to build - today - an enterprise CRUD application in .NET that has an n-tier architecture. What approach to data access should you use? I want interoperability, which is why there are no DataSets (and I suppose it's not 2003). Likewise, the .NET RIA Services advertised a method of providing its functionality through an add-on to non-Silverlight clients does not seem very compelling to update the operation. I've somehow managed to tie something with Entity Framework which doesn't have n-tier OOB support and so it took a lot of weird reflection type stuff to simulate the appearance of optimistic concurrency (the example in MSDN Magazine doesn't look like it supports optimistic concurrency. i hear this is improved in EF4 but Im a bit skeptical and not available but in CTP).
So what can people actually do in their projects for enterprise CRUD with optimized concurrency checking? DataSets? DIY with DTO and lord knows how much work? And how does it work with linked data? Let's say I have a collection associated with a DataGrid, I need to listen to the CollectionChanged for changes? Do I need to save stacks of changes so that I can compare PCs if reversed? Sounds nightmarish.
And second, what if checking for updates for optimistic concurrency required a tough requirement? What then?
source to share
First of all, if you plan on migrating 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 a strong contender against the likes of nHibernate and friends in my opinion. EF is a central player in many of Microsoft's future data initiatives, so it cannot be ignored as easily as it once did. It, or any of the earlier .NET 4.0 frameworks that depend on it, should serve your CRUD needs well.
As an aside, I would just make sure that a simple CRUD approach is best for a business perspective ... CRUD makes a ton of sense from a technical point of view, and in small applications it is usually the right choice. But you used the term enterprise, so I'm wondering if your application has a broader scope than the simplicity of CRUD.
Anything outside of your small scale company with a total of 20 to 50 employees and I would look at Domain Driven Design (DDD) and SOA. If you want things like concurrency management and the like, the executives that manage DDD should serve you well. SOA is usually useful for extremely large projects where you have many development teams working on multiple projects at the same time that need to interact with each other. It might be overkill for your needs, but there are some good guidelines that can help.
source to share