asp.net - 我的服务层中的服务是否应该位于单独的项目/DLL/程序集中？

Question

我目前正在开发一个 ASP.NET MVC 3 应用程序。我正在实现一个服务层，其中包含业务逻辑，并由 Controller 使用。服务本身利用存储库进行数据访问，存储库使用 Entity Framework 与数据库通信。

所以从上到下是: Controller >服务层>存储库(每个服务层依赖于单个可注入(inject)存储库)> Entity Framework >单个数据库。

我发现自己正在制作诸如 UserService、EventService、PaymentService 等项目。

在服务层，我将具有以下功能:

• ChargePaymentCard(int cardId, 小数金额)(部分 支付服务)
• ActivateEvent(int eventId)(EventService 的一部分)
• SendValidationEmail(int userId)(UserService 的一部分)

此外，作为我使用此服务的第二个地方的示例，我有另一个作为计划任务运行的简单控制台应用程序，它使用其中一个服务。还有即将推出的第二个 Web 应用程序，需要使用其中的多个服务。

此外，我希望我们对拆分事物(例如我们的单一数据库)持开放态度，并愿意转向面向服务的架构，并将其中一些分解为 Web 服务(可以想象，甚至是有一天会被非 .NET 应用程序使用)。我一直在密切关注可能会减轻向 SOA 飞跃的痛苦的步骤。

我已经开始为每个服务创建单独的程序集(DLL)，但我想知道我是否开始了错误的道路。我试图保持灵活性并保持松散耦合，但是这条路径对我有帮助吗(面向 SOA 或一般情况)，还是只是增加了复杂性？我是否应该创建一个包含整个服务层的单个程序集/dll，并在需要使用任何服务的地方使用该单个程序集？

我不确定我要开始的路径的含义，因此我们将不胜感激!

Answer 1

IMO - 答案是这取决于您应用程序的很多因素。

假设您正在构建一个不平凡的应用程序(即不是学习 SOA 的大学/业余爱好项目):

• 用户服务/事件服务/支付服务 -- 创建自己的 DLL 并将其公开为 WCF 服务(如果有多个应用程序使用该服务，并且将 DLL 共享给不同的应用程序风险太大
  -- 这些服务之间不应该相互依赖，并且应该专注于各自的领域
  -- 注意:这些服务可能共享一些通用服务，例如日志记录、身份验证、数据访问等。

• 创建合成服务 -- 该服务将跨所有其他服务进行调用组合
  -- 例如:如果您已下订单，业务流程为下订单 > 确认用户存在(用户服务) > 引发 OrderPlaced 事件(事件服务) > 确认付款(支付服务)
  -- 所有此类服务调用组合都可以在这一层处理
  -- 同样，根据环境，您可以选择将此服务公开为其自己的 DLL 和/或将其公开为 WCF
  -- 注意:这是唯一一个将共享对其他服务的引用的服务，并且将成为单点组合

现在 - 使用此布局 - 如果您想单独与该服务交互，您将可以选择直接调用服务；如果您需要需要不同服务的业务工作流程，则需要调用组合服务组成以完成交易。

作为起点，我建议您阅读任何有关 SOA 架构的书籍 - 它将有助于澄清许多概念。

我试图尽可能简短，以使这个答案有意义，有很多方法可以做同样的事情，这只是其中一种可能的方法。

HTH。