我的服务层中的服务应该位于单独的项目/ DLL /程序集中吗？

Question

我正在使用一个ASP.NET MVC 3应用程序。我正在实现一个服务层，它包含业务逻辑，并由控制器使用。服务本身利用存储库进行数据访问，存储库使用实体框架与数据库进行通信。

所以从上到下是：控制器＆gt;服务层＆gt;存储库（每个服务层依赖于单个可注入存储库）＆gt;实体框架＆gt;单个数据库。

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

在服务层，我将拥有以下功能：

• ChargePaymentCard(int cardId, decimal amount)（部分 PaymentService）
• ActivateEvent(int eventId)（EventService的一部分）
• SendValidationEmail(int userId)（UserService的一部分）

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

此外，我希望让我们保持开放的态度（例如我们的单一数据库），并转向面向服务的架构，并将其中的一些打破到Web服务中（可以想象甚至是某天由非.NET应用程序使用）。我一直睁大眼睛看看可能会让SOA的飞跃在未来的道路上变得更加痛苦的步骤。

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

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

Answer 1

IMO - 答案取决于您申请的很多因素。

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

• 用户服务/活动服务/付款服务 - 创建自己的DLL＆amp;如果有多个应用程序使用此服务，并且将DLL共享给不同应用程序的风险太大，则将其公开为WCF服务 - 这些服务之间不应存在相互依赖关系。应该关注他们各自的领域 - 注意：这些服务可能共享一些常见服务，如日志记录，身份验证，数据访问等。

• 创建合成服务 - 此服务将执行所有其他服务的呼叫组成
  - 例如：如果您已下订单＆amp;业务流程是订单已放置＆gt;确认用户存在（用户服务）＆gt;提出OrderPlaced事件（事件服务）＆gt;确认付款（付款服务）
  - 所有这些服务组合的组合都可以在这一层处理 - 同样，根据环境的不同，您可以选择将此服务公开为自己的DLL和/或将其作为WCF公开 - 注意：这是唯一可以共享对其他服务的引用的服务。将是单一的构成点

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

作为一个起点，我建议您阅读有关SOA体系结构的任何书籍 - 它将有助于清除许多概念。

我尽量缩短以保持这个答案的意义，有很多方法可以做同样的事情，这只是其中一种可能的方式。

HTH。

Answer 2

每个服务有一个DLL听起来像个坏主意。根据Microsoft的说法，由于性能影响（从here到this post），您希望在多个较小的组件上安装一个大型组件。

我会将您的基础或核心服务拆分为一个单独的项目，并保留大部分（如果不是全部）服务。根据您的需要，您可能拥有仅在Web项目或控制台应用程序的上下文中有意义的服务，而不是其他任何地方。这些服务不应该是“核心”服务层的一部分，而应该存在于适当的项目中。

Answer 3

最好将服务与消费者分开。在我们的项目中，我们有两个层次的分离。我们曾经将所有服务接口分组到一个Visual Studio项目中。所有服务实现都分组到另一个项目中。 服务的消费者需要引用两个dll，但它使解决方案更易于维护和扩展。我们可以有多个服务实现。 对于例如服务接口可以在interfaces项目中定义WebSearch的合同。并且可以通过不同的搜索服务提供商（如Google搜索，Bing搜索，Yahoo搜索等）实现WebSearch的多种实现。