c# - 关于使用哪些服务以及按什么顺序的决定是否构成 MVC Controller 方法中的逻辑？

Question

我正在开发的一个新的 ASP.NET MVC 应用程序即将结束，我意识到我并没有 100% 明白我的 Controller 方法中应该发生什么。

由操作方法决定调用哪些服务/方法以及调用顺序是否更好:

AccountService _accountService;
BillingService _billingService;
InvoiceService _invoiceService;

...    

public ActionResult UpgradeAccountPackage(PackageType packageType, int accountId)
{
    _accountService.UpgradeAccountPackage(packageType, accountId);
    _billingService.BillForAccountUpgrade(packageType, accountId);
    _invoiceService.CreateAccountUpgradeInvoice(packageType, accountId);
}

或者坚持对一个服务进行单一方法调用并允许该方法调用它需要的其他服务/支持方法是否更好？

public ActionResult UpgradeAccountPackage(PackageType packageType, int accountId)
{
    // account service upgrades account then calls the BillingService and InvoicService
    // methods called above within this method
    _accountService.UpgradeAccountPackage(packageType, accountId);
}

我倾向于在这里使用第二个示例，因为最初似乎第一个方法会以某种方式构成逻辑，并且意味着 acion 方法必须本质上了解帐户升级过程在我的应用程序中如何工作，这似乎是一件坏事。

但是，现在我的应用程序几乎完成了，它有一个很大的服务层，这种方法导致几乎每个服务都强烈依赖于许多其他服务，并且没有集中的地方来决定业务事务的流程，例如上面提到的，您必须在服务方法中深入研究一下才能发现流程。

我正在考虑重构以更类似于上面的第二种方法，或者在 Controller 和服务层之间引入一个新层来控制流程。

人们倾向于使用第一种方法还是第二种方法？人们的意见是什么？

Answer 1

我更喜欢第二种方法 - 更容易测试(使用模拟)，并且逻辑可以重用。您最终会得到实际业务逻辑的外观，但这并不是坏事。

我不明白为什么你的服务层充满了具体的依赖关系......

要记住的是，您希望类依赖于接口(interface)，而不是实现。 (然后使用依赖注入(inject)工具将它们串在一起)

在C#中，我们可以让一个类实现多个接口(interface)。因此，您的服务实现可以实现许多接口(interface)，而调用者只需要知道他们需要的部分。

例如，您可能有一个实现 IDepositor 和 IWithdrawer 的 AccountTransactionService。如果您实现复式记账，那么这可能取决于 IDepositor 和 IWithdrawer，实际上，它们只使用相同的 AccountTransactionService 实例>，但不是必须的，之后可以更改实现细节。

一般来说，一个类对系统中其他类的了解越少越好。