2

我正在重新构建一个大型 Web 表单 ASP.Net 应用程序，插入一个服务层以从表示层中消除不必要的责任。

我见过很多例子，所有的服务方法都包含在一个类中。

这是常见/最佳做法吗？或者在服务层中拥有多个服务类是否完全可行？我倾向于拥有不止一项服务，并且这些服务能够相互通信。

任何指导，优点/缺点？

理查德

Ps 请注意，我不是在谈论Web服务层、WCF 或其他，尽管以后可能会变得更加相关。

4

3 回答 3

3

SOLID 原则，特别是单一职责原则表明，将所有功能放在一个对象中是一个坏主意，我倾向于同意。随着应用程序的增长，单个类将变得难以维护。

您对 Yuriys 回答的评论会建议您使用 IOC 容器。让我们更详细地考虑一下……

这个类包含的功能越多，它需要的依赖项就越多。您很可能最终在服务上拥有一个具有一长串参数的构造函数，这仅仅是因为该类涵盖了很多领域并且依赖于较低级别的其他功能，例如日志记录、数据库通信、身份验证等。让我们说该服务的消费者希望在销毁实例之前调用该类上的一个且仅一个特定方法。您的 IOC 容器将需要注入服务在运行时可能“可能”需要的每个依赖项，即使消费者只会使用这些依赖项中的 1 个或 2 个。

同样从操作的角度来看 - 如果团队中有多个开发人员同时在服务层上工作，那么如果你们都在编辑一个文件，则合并冲突的可能性更大。但是，正如建议的那样，您可以使用部分来解决这个问题。

通常，与众所周知的模式或原则相结合的实用性是最好的前进方式。

如果您还没有研究过面向服务的架构，我建议您研究一下，因为它可以帮助您回答解决方案方法中的一些关键决策。

于 2012-10-13T07:22:55.647 回答
2

当然可以。此外，我认为最好从这个上帝服务层类中按功能提取几个接口（即ISecurityService、INotificationService等），并在单独的项目中实现每个接口。此外，您可以利用一些 IOC 容器来解析实现服务接口的类。这样，您可以独立更改每个服务的实现，而无需更改客户端功能。

至少，您第一次可以将您的服务超类标记为部分，然后按功能将其拆分为几个具有有意义名称的 .cs(.vb) 文件，并在 Visual Studio 中将它们组合在一起。这将简化跨服务方法的导航。

于 2012-10-11T07:59:09.623 回答
0

我对构建应用程序的看法是首先将应用程序拆分为两个项目 AppX.Web（UI 逻辑）和 AppX.Business（业务逻辑），但仍将它们保留在同一个 VS 解决方案中。业务逻辑和 UI 逻辑之间的结构澄清有助于您了解哪些服务在多个网页之间共享，哪些服务是单个网页的本地服务。您应该避免在网页之间直接重用代码，如果您发现这是必要的，那么您应该将那段共享代码移动到业务逻辑层。

在实现业务逻辑项目时，您应该尝试为不同类型的业务逻辑创建单独的类。这些类当然可以互相交谈，但要避免让网页互相交谈。

将 UI 逻辑与业务逻辑分离后，如有必要，您可以继续将 AppX.Business 代码分解为更小的部分。常见的例子包括：

  • AppX.Data：将所有数据操作与实际业务逻辑隔离开的数据访问层 (DAL)
  • AppX.Dto：数据传输对象（DTO），在许多场景中都很有用，例如，将数据发送到客户端浏览器以供 jQuery 处理时
  • AppX.Common：对许多其他应用程序通用的共享逻辑，这可以是您之前创建的帮助类，也可以是在项目结束后应审查的内容，以包含在公司范围的支持类中。

最后，让我们谈谈全力以赴并将您的业务逻辑公开为 WCF 服务。在这种情况下，您实际上不需要更改现有结构中的任何内容。您可以将 WCF 服务添加到现有的 AppX.Web 项目中，也可以在 AppX.Service 中单独公开它们。如果您已将业务逻辑与 UI 逻辑正确分离，则 WCF 层可以只是业务逻辑的薄包装。

在实现 WCF 服务时，很可能在一个类中完成所有这些工作。WCF 服务中没有真正的业务逻辑可用，因为它只是直接调用业务逻辑。

如果您构建一个新应用程序，您应该预先考虑您的整体设计，但是现在您正在重新架构，我认为您应该逐步工作：

  • 首先创建 AppX.Web 和 AppX.Business 项目
  • 识别服务并在 AppX.Business 中为这些服务创建类
  • 将 AppX.Web 项目中的代码移动到 AppX.Business 中的新类中，并确保从 Web 项目中调用它们。
  • 如果您觉得需要，请继续进行额外的细分！
于 2012-10-13T07:07:23.970 回答