比我的.net程序集解决方案更好的数据库访问层解决方案

对于即将到来的工作，我将着眼于对现有系统的部分重写。其中一部分是DAL，它是作为。net程序集实现的，由一些应用程序引用，并提供将内容推送到底层DB和从该DB检索数据的方法。从本质上讲，我为DLL的用户提供了一种连接到某些数据库并对其进行有限调用的方法。而不是用户自己编写SQL，他们使用我定义的接口。

现在已经有关于使用一些数据访问服务层来代替现有DLL的讨论，这种方法的支持者引用的好处是它是"可维护的"，"可测试的"，"可扩展的"——所有标准的流行语。也有人声称，这种方法在某种程度上最小化了对使用该层的应用程序的影响，因为它隔离了更改，尽管我不相信这是事实。在我看来，底层数据库和应用程序之间的任何一层都将有一个定义良好的接口，因此在任何一方所做的更改，如果不涉及接口的另一方，将是不可见的，也没有真正的影响。同样，任何对产生影响的更改也可能需要对中间层进行更改。我不明白为什么它不会。

预计需要对DAL进行早期更改，因为，嗯，东西会发生变化。方法参数发生变化，导致我当前重新编译DAL程序集并将其分发给DAL的用户。这种情况并不经常发生，但确实发生了。我在这方面可能有点幼稚，但我不知道还有什么比我目前拥有的更好的方法来让应用程序脱离数据库接口业务。有人对提供更好的模块化的DAL解决方案有具体的了解吗?我在这里和网上其他地方读过一些帖子，但没有一个真正谈论这个。如果有一个问题已经解决了这个问题，我很有兴趣看到这个链接，并很乐意关闭这个问题。

---

附加信息:

我上面的长问题的一个简短版本是"不使用我目前使用的DLL方法的优势是什么?"我目前使用的模型具有以下特征:

• 一些抽象底层DB模型的POCO类(这些类目前不是自动生成的，而是手工构建的，尽管我猜它们可以通过EF或类似的东西自动生成，尽管我不确定这真的很重要)
• 一系列可调用的公共方法，如GetOrderDetails(int orderID)或SubmitOrder(Order newOrder)
• 它通过应用程序使用DLL提供的输入来处理DB连接字符串