Designing a Database Layer DLL to support drop-in replacement

I am wondering if there is an intelligent way to design a C# dll such that you can later rebuild it and use the new version as a drop-开发者_C百科in replacement in a "safe" manner. Safe mostly means the signatures don't change.

I was contemplating the differences between using a database primarily via LINQ vs using it primarily with stored procedures. On advantage of stored procedures is that you can change any individual stored procedure without doing a recompile/republish of your application. So, I was contemplating what it would take to have a similar ability by creating a solution where all of the database-oriented code was in a separate project using fun stuff like dbml files and whatnot . Obviously if you stuff garbage on the inside of one of your replacement LINQ functions, the replacement will cause issues, but this disadvantage exists.

The main sort of rules I came up with are just:

• If the database model changes, it is time to do a recompile.
• Protection against any of the signatures changing. No existing public methods should be removed.

My intuition is that a big part of doing this would involve the use of an interface that was referenced by the separate project and used by the main project in order to make all the calls.

So, does this idea make sense? Are there any strategies that should be used to make this reasonably safe (i.e. without adding much new risk beyond that associated with editing stored procedures without rebuilding an application)?

What you describe are called Repositories and they are part of Domain Driven Design. Combined with ORM (NHibernate, Entity Framework), this will give you some flexibility.

However, you will still get problems. When you get a new field in the database, your class structure will change because you get new public fields.

I'm not sure whether it's possible to have a database layer that is separated from your code base so completely you can simply replace your DLL's, but the above may be a starting point to get there.

It is possible to separate the db layer such that you can just deploy new DLL's. We took a similar approach with our projects.

Note that we did NOT implement LINQ or any other ORM tool. Instead, our DAL code uses the regular database access as provided through Enterprise Library.

The key was that the assembly has both the classes and the "providers" responsible for loading and persisting the classes. When we make a s'proc signature change then we'll update the appropriate assembly. Sometimes this necessitates adding additional fields to a class definition.

At the time we add those fields we make a determination as to whether they are required or not. If they are, then this means the main code will have to be modified to support that and the whole thing deployed together. If not, then we can just deploy the new data access assemblies separately from the main code base.

That said, it's a rare day that changes to our object model are not reflected in the main code base in some manner (new entry fields for example). Changes to s'proc internals happen often enough, but those are handled completely in SQL and do not require the DAL to be updated.