比我的 .NET 程序集解决方案更好的数据库访问层解决方案？
对于接下来的工作，我将考虑对现有系统进行部分重写。其中一个部分是 DAL，它作为 .NET 程序集实现，由一些应用程序引用，并提供将事物推送到底层数据库并从该数据库检索数据的方法。本质上，我为 DLL 的用户提供了一种连接到某些数据库并对它进行有限的调用的方法。他们使用我定义的接口，而不是用户自己编写 SQL。
现在已经有关于使用某些数据访问服务层代替现有 DLL 的讨论，这种方法的支持者提到的好处是它是“可维护的”、“可测试的”、“可扩展的”——所有标准流行语。还有人声称，这种方法在某种程度上最大限度地减少了对使用该层的应用程序的影响，因为它隔离了更改，但我不相信情况确实如此。在我看来，底层数据库和应用程序之间的任何层都将具有定义良好的接口，因此在任何一侧所做的不涉及接口另一侧的更改将是不可见的并且不会产生真正的影响。同样，任何影响另一方的更改也可能需要更改中间层。我不明白怎么会不会。
预计 DAL 需要尽早进行更改，因为内容会发生变化。方法参数发生变化，导致我当前重新编译 DAL 程序集并将其分发给 DAL 用户。这些情况并不经常发生，但确实发生了。我在这方面可能有点天真，但我不知道还有比我目前所采用的方法更好的方法来使应用程序脱离数据库接口业务。有人对提供更好模块化的 DAL 解决方案有具体了解吗？我在这里和网上其他地方读过一些帖子，但没有一个真正谈论这个。如果现有的问题已经解决了这个问题，我有兴趣看到这个链接，并且很乐意结束这个问题。
其他信息：
上述长问题的简短版本是“不使用我目前采用的 DLL 方法有什么优势？”我当前使用的模型具有以下特征：
- 许多 POCO 类，它们抽象了底层数据库模型（这些类当前不是自动生成的，而是手工构建的，尽管我猜它们可以通过 EF 或类似的东西自动生成虽然我不确定这真的很重要）
- 许多可以调用的公共方法，例如
GetOrderDetails(int orderID)或SubmitOrder(Order newOrder) - 它处理数据库连接字符串通过应用程序使用 DLL 提供的输入
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 be 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)orSubmitOrder(Order newOrder) - It handles the DB connection string via inputs which are provided by the app using the DLL
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为不知道任何细节，假设较小的项目没有太多客户端，我会说坚持使用 dll，并确保最新版本位于文件共享上或位于可以通过脚本下载的 url 上，最好是自动构建过程。
啊，不太确定数据访问服务层是什么意思。
我认为对此提供良好的反馈，我们需要知道有多少客户端、客户端类型、其中包含哪些类型的方法（我认为复杂对象的大量选择查询不太适合 WCF 或类似的）。另外，由于 WCF 用途广泛，是否可以在同一台计算机上、通过 LAN、通过 Internet 进行操作？
我曾经稍微使用过 WCF，但实际上并没有在这种情况下使用过。
只要您所做的所有更改不违反合同（仅添加新方法），它可能比您的 DLL 稍微更加模块化，但我想说，如果您需要从不同平台或足够的客户端访问它，那么巨大的好处将会到来数据库连接将会紧张。
WCF 的某些错误可能难以调试。如果您确实必须违反合同，则必须向他们发送一个新的 servicecontract.cs 文件
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
根据我对您的问题和客户愿望的理解，我相信他们正在谈论一些类似于 SOA 或面向服务的架构的内容。根据 SOA 原则，它确实允许采用模块化和松散耦合的方法。这可以导致更容易的维护，因为可以改变、更新和/或维护数据访问例程的逻辑而不影响客户端。另外，假设您有 20 个使用“服务”的客户端 - 无需为所有使用“服务”或 DAL 的客户端更新和部署新的 dll。
就用于实现 SOA 系统的平台或技术而言，您可以选择任何平台或技术。或者更准确地说，无论什么工具都是适合这项工作的。您可以自己推出，可以使用 WCF，也可以使用 WebAPI...等等...
以下是有关该主题的一些链接：
SOA 简介 - JavaWorld
.NET 面向服务的架构 < /一>
<一href="http://www.c-sharpcorner.com/UploadFile/john_charles/Service_Oriented_Architecture_and_Microsoft_NET01202006080616AM/Service_Oriented_Architecture_and_Microsoft_NET.aspx" rel="nofollow">面向服务的体系结构和 Microsoft .NET
MS 架构杂志 #21 - SOA 的今天和过去
了解面向服务的体系结构
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