Database Development – Is Writing Your Own Data Access Layer a Good Idea?

database-developmentdesign-patternsentity-frameworknhibernate

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.

Best Answer

Both arguments against existing ORMs are invalid:

"Well at least we'll be in control of our own code"

Why not write your own language? Your own framework? Your own operating system? And to be sure you're in control of everything, it's also a good idea to create your own hardware.

"Oh I've used L2S/EF in a previous project and it was nothing but headaches"

EF is mature enough and was used successfully by plenty of people. It means that a person who claims that EF is nothing but a headache should probably start learning how to use EF properly.

So, do you have to write your own ORM?

I wouldn't suggest that. There are already professional-level ORMs, which means that you have to write your own only if:

You have a precise context where all existing ORMs cannot fit for some reason,
You are sure that the cost of creating and using your own ORM instead of learning an existing one is much lower. This includes the cost of future support, including by another team of developers who would have to read hundreds of pages of your technical documentation in order to understand how to work with your ORM.

Of course, nothing forbids you to write your own ORM just out of curiosity, to learn things. But you should not do it on a commercial project.

See also points 2 to 3 of my answer to the question Reinventing the wheel and NOT regretting it. You can see that the different reasons for reinventing the wheel don't apply here.

Related Solutions

Repository Pattern – How to Implement for Complex Object Models

First, you will run through every entity that you have and ask yourself :

Does it make sense to persist this entity alone?

What I mean here, is that in your object model, some entities are likely contained in others in a master-detail relationship. If your entity is highly dependant on another, do not create a repository for this entity alone because it won't likely be persisted by itself. Instead, you will create a repository for each parent class, and you will make sure that the child entities and other relations are persisted at the same time.

I don't like how they implemented the UnitOfWork pattern in the link you provided. I suggest you to do something more along these lines. You don't have to define one class per repository. The same class can be used for every repository, each having their own instance of the UnitOfWork class for the lifetime of the operation. You can also reuse the same UnitOfWork in different repositories for changes that you want persisted at the same time.

Dependency Injection – Abstract Factory Patterns in C#

It seems you're struggling trying to create objects that create objects... wouldn't you be better off just creating objects ?

Ninject allows you to do so in a very simple way :

// Ninject module
Bind<IRepository<SomeEntity>>().To<SomeEntityRepository>();

// injected class
public class SomeService
{
  public SomeService(IRepository<SomeEntity> repository)
  {
    // ...
  }
}

// get instance of injected class
var someService = kernel.Get<SomeService>();

I can't see the benefit of an abstract factory in addition to an IoC container when you're creating objects based on basic, compile-time-known constraints such as in your SomeViewFactory and SomeRepositoryFactory examples.

The dynamic nature of SomeFunctionalityFactory would be more debatable, but when you think of it, do you really need to instantiate an object with the built-in notion that it will never be able to be used by the current user ? Wouldn't it make more sense to have the object evaluate user authorization when the functionality is called ?

Best Answer

Related Solutions

Repository Pattern – How to Implement for Complex Object Models

Dependency Injection – Abstract Factory Patterns in C#

Related Topic