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

Question

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

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

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

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

ChargePaymentCard(int cardId, decimal amount) (部分
支付服务)

ActivateEvent(int eventId) (EventService 的一部分)

SendValidationEmail(int userId) (用户服务的一部分)

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

此外，我想让我们对拆分事物(例如我们的单个数据库)保持开放态度，并在 future 转向面向服务的架构，并将其中的一些分解为 Web 服务(甚至可以想象非-.NET 应用程序有一天)。我一直在睁大眼睛寻找可能使向 SOA 的飞跃在 future 不那么痛苦的步骤。

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

我不确定我开始的路径的含义，所以对此的任何帮助将不胜感激!

Answer 1

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

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

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

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

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

作为起点，我建议您阅读任何有关 SOA 架构的书籍——这将有助于理清很多概念。

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

HTH。