我的网络服务的这种“分层”是否正确？可以改进吗？答案

【问题标题】：Is this 'layering' of my web-service correct? Can it be improved?我的网络服务的这种“分层”是否正确？可以改进吗？
【发布时间】：2010-07-14 05:14:20
【问题描述】：

我正在编写一个 Web 服务来从数据库表中检索发票信息。具体如下：
我打算将InvoiceAgentId 作为输入并检索PayerId、PayerName、EffDate 和InvoiceAgentId。
现在，
1. 在InvoiceInfoSearch.asmx.cs 文件中我有WebMethod ... GetInvoiceInfo
2. 我有 DTO 对象 InvoiceInfoRequest 和 InvoiceInfoResponse
3. 我有BusinessLayer 经理类InvoiceSearchmanager
4. 我有 DAL InvoiceInfoDAL

第 1 点中的 Web 方法实例化 InvoiceSearchManager 类并通过传递 InvoiceInfoRequest 调用管理器中的 GetInvoiceInfo 方法。然后 manager 方法实例化 InvoiceInfoDAL 并通过传递 InvoiceInfoRequest 调用 DAL 中的 GetInvoiceInfo 方法。在 DAL 方法中，InvoiceInfoResponse 被实例化并填充检索到的记录集，然后传播回 Web 方法。

我的问题：
1. InvoiceInfoRequest 和InvoiceInfoResponse DTO 类可以有完全相同的成员吗？就我而言，PayerId、PayerName、EffDate 和 InvoiceAgentId。
2.这个分层正确吗？可以改进吗？

【问题讨论】：

您仍在使用 ASMX Web 服务有什么原因吗？微软现在认为它们是“遗留技术”。
相信我……我的企业中还有更多的遗产……比我想要的还要多……而 asmx 是我最不关心的 :)。我们在框架方面不断进步……但总体编码标准仍有很多需要整合。

标签： c# web-services dto

【解决方案1】：

从分层的角度来看，您的描述看起来不错。您可以在 DAL 和业务层中使用相同的方法名称。问题在于紧密耦合。正如您所描述的那样，您的 Web 层实例化了实例化 DAL 层的业务层。

如果是这种情况，您打算如何单独对业务层进行单元测试？

我建议您为 DAL 和业务层引入一个抽象级别（通过让它们实现接口）。然后业务层实现可以将 DAL 接口作为构造函数参数（构造函数注入），而不是让它实例化 DAL。

这种抽象级别将允许您在单元测试中用模拟对象替换真正的 DAL，并单独测试业务层。

所有管道（实例化）都将在 Web 层完成。

【讨论】：

感谢您的回复！请求和响应 DTO 对象具有完全相同的成员是否可以？
为了更进一步，研究一个依赖注入框架，例如 Spring.NET 或类似的。这将创建一个“应用程序上下文”——一个注册表，其中可以在给定接口的情况下实例化或检索层。注册表中的层可以通过配置来定义。
如果请求和响应 DTO 成员相同，则您可以将相同的类用于请求和响应：确实，这种情况我已经见过很多次了。但是，经常发生以后的更改需要不同的成员来请求和响应，并且解开紧密耦合是一件非常痛苦的事情。所以最好从一开始就让它们分开......

【解决方案2】：

这完全是口味问题，但我的方法会更简单：

Controller (eg your *.asmx.cs) -> 
  Business Services ->
    DAL

由你决定。然而，我的架构是基于 java 世界中的 spring 和 hibernate 的工作原理（例如，不与谷物摩擦）。我假设 C# 遵循类似的架构。

【讨论】：

您描述的分层似乎与 OP 使用的相同。