Better solutions for a Database Access Layer than my .NET assembly solution?

For an upcoming effort I'll be looking at a partial rewrite of an existing system. One piece of it is a DAL which is implemented as a .NET assembly that is referenced by a few applications and provides methods to push things to an underlying DB and retrieve data from that DB. Essentially, I provide the users of the DLL with a means to connect to some DB and make a limited set of calls to it. Rather than the users writing SQL themselves, they use my defined interface.

Now there have been discussions about using some data access service layer instead of the existing DLL and the cited benefits by the proponents of this approach are that it is "maintainable", "testable", "scaleable" - all the standard buzzwords. There was also claims that this approach somehow minimizes the impact on the applications using the layer because it isolates the changes, though I'm not convinced this is the case. It would seem to me that any layer between the underlying DB and the application is going to have a well-defined interface and so changes made on either side which don't involve the other side of the interface will be invisible and have no real impact. Too, any changes which do affect the other side would may require changes to that middle layer as well. I don't see how it wouldn't.

It's expected that early on changes will be required to the DAL because, well, stuff changes. Method parameters change and it causes me currently to recompile the DAL assembly and distribute it to the users of the DAL. These don't happen too often but they do. I may be a bit naive in this area but I'm not aware of a better way to get the applications out of the DB-interfacing business than what I currently have in place. Does anyone have specific knowledge about DAL solutions which provide for better modularity? I've read a few posts here and elsewhere on the net but none really talking about this. If there's an existing question that addresses this already, I'd 开发者_StackOverflowbe interested in seeing a link to this and would be happy to close this question.

Additional info:

A shorter version of my long question above is "What would be an advantage of not using the DLL approach that I currently employ?" The current model I employ has the following characteristics:

• A number of POCO classes which abstract the underlying DB model (these classes are not currently auto-generated but were hand-built, though I guess they could be auto-generated via EF or something like that though I'm not sure it really matters)
• A number of public methods which can be called, e.g., GetOrderDetails(int orderID) or SubmitOrder(Order newOrder)
• It handles the DB connection string via inputs which are provided by the app using the DLL

My opinion not knowing any of the details, assuming smaller project with not too many clients, I'd say stick with the dll, and make sure the latest version of that is on a fileshare or at a url that can be downloaded by a script, preferably the build process automatically.

Ah, wasn't exactly sure what you meant by data access service layer.
I think giving good feedback on this we'd need to know how many clients, types of clients, what kind of methods would be in it (i think huge select queries of complex objects would be a poor fit for WCF or similar). Also since WCF is so versatile, would this be on the same machine, over a LAN, over the internet?

I've used WCF slightly, but not in that context really.

It might be slightly more modular than your DLL as long as all the changes you make do not break the contract (only adding new methods) but I'd say the big benefit would come if you needed it accessed from different platforms, or enough clients that database connections would be strained. Some errors with WCF can be difficult to debug. And if you do have to break the contract you have to send them a new servicecontract.cs file for that still

In my understanding of your question and the client's desire, I believe they are talking about something along the lines of SOA or Service Oriented Architecture. According to the SOA principle it does allow for a modular and loosely coupled approach. This can lead to easier maintenance in that the logic of the data access routine can be altered, updated and/or maintained without affecting the clients. Also, say, you have twenty clients that make use of the "service" - there will be no need to update and deploy a new dll to all of the clients that make use of the "service" or DAL.

In terms of the platform or technology used to implement SOA systems, it could be whatever you chose. Or more accurately, whatever is the right tool for the job. You could roll your own, you could use WCF or you could also make use of WebAPI... etc...

Here are some links on the topic:

Introduction to SOA - JavaWorld

Service Oriented Architecture with .NET

Service Oriented Architecture and Microsoft .NET

MS Architecture Journal #21 - SOA Today and Past

Understanding Service Oriented Architecture