We're currently in a situation where we have a choice between using an out-of-the-box object-relational mapper or rolling our own
We have a legacy application (ASP.NET + SQL Server) where the data-layer & business-layer are unfortunately mashed together. The system isn't particularly complicated in terms of it's data access. It reads data from a large group (35-40) of inter-related tables, manipulates it in memory & saves it back to some other tables in a summary format. We now have opportunity for some refactoring and are looking at candidate technologies to use to seperate & properly structure our Data Access.
Whatever technology we decide on we would like to:
- have POCO objects in our Domain Model which are Persistence Ignorant
- have an abstraction layer to allow us to Unit Test our domain model objects against a mocked up underlying datasource
There's obviously lots of stuff out there on this already in terms of Patterns & Frameworks etc.
Personally I'm pushing for using EF in conjunction with the ADO.NET Unit Testable Repository Generator / POCO Entity Generator. It satisfies all of our requirements, can be easily bundled inside a Repo/UnitOfWork Pattern and our DB Structure is reasonably mature (having already undergone a refactor) such that we won't be making daily changes to the model.
However others in the group are suggesting architecting/rolling our own D.A.L. completely from scratch. (Custom DataMappers, DataContexts, Repository, Interfaces everywhere, Dependency Injection overkill to create concrete objects, Custom LINQ-to-Underlying Query Translation, Custom Caching Implementations, Custom FetchPlan Implementations...) the the list goes on and to be frank is strikes me as madness.
Some of the arguments been thrown about are "Well at least we'll be in control of our own code" or "Oh I've used L2S/EF in a previous project and it was nothing but headaches". (Although I've used both in Production before and found any issues to be few and far between, and very manageable)
So do any of your uber-experienced devs/architects out there have any words of wisdom that might help me steer this product away from what seems to me like it's going to be a complete disaster. I can't help but think that any benefit gained by dodging EF issues, will be lost just as quickly by attempting to re-invent the wheel.