2

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

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

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

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

  • ChargePaymentCard(int cardId, decimal amount)（支付服务的一部分）
  • ActivateEvent(int eventId)（事件服务的一部分）
  • SendValidationEmail(int userId)（用户服务的一部分）

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

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

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

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

4

3 回答 3

2

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

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

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

  • 创建一个组合服务 ——该服务将对所有其他服务的调用进行组合
    ——例如：如果您有一个订单并且业务流程是该订单 > 确认用户存在（用户服务）> 提出一个订单event (Event Service) > Confirm Payment (Payment Service)
    -- 所有此类服务调用的组合都可以在这一层处理
    -- 同样，根据环境，您可以选择将此服务公开为它自己的 DLL 和/或公开它作为 WCF
    - 注意：这是唯一一个共享对其他服务的引用的服务，并且将是单点组合

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

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

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

HTH。

于 2012-05-02T17:18:48.517 回答
1

每个服务都有一个 DLL 听起来是个坏主意。根据 Microsoft 的说法，由于性能影响（从这里通过这篇文章），您希望在多个较小的程序集上拥有一个大型程序集。

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

于 2012-05-02T16:57:21.317 回答
0

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

于 2012-05-10T07:19:20.757 回答