依赖注入 vs 分层架构 [英] Dependency Injection vs Layered Architecture

问题描述

我已经阅读了很多关于依赖注入和服务定位器(反?)模式的内容——在 StackOverflow 上有很多(谢谢大家:).我对这种模式在 n 层架构中如何工作有疑问.

I've been reading a lot about dependency injection and the service locator (anti-?) pattern - a lot of it on StackOverflow (thanks guys :). I have a question about how this pattern works when it's within a n-layer architecture.

我看过很多博客文章，其中描述了将 IDataAccess 组件注入到业务对象中.例如

I've seen a lot of blog posts where they describe injecting a IDataAccess component into the business objects. E.g.

public class Address
{
    IDataAccess _dataAccess;
    public Address(IDataAccess dataAccess)
    {
        this._dataAccess = dataAccess;
    }
}

然而，我的印象是，在 n 层架构中，UI 层不应该需要对数据访问层有任何了解……甚至不知道有/是/数据访问层！如果 DI 需要在 BusinessObjects 的构造函数中公开 IDataAccess 接口，那么这会向 UI 公开以下事实:业务层在幕后使用数据访问层 - UI 不需要知道或关心这些内容吗?

However, I was under the impression that in an n-layer architecture, the UI layer should not need to have any knowledge of the data access layer... or even know that there /is/ a data access layer! If DI requires exposing the IDataAccess interface in the constructors of the BusinessObjects, this then exposes to the UI the fact that the Business Layer uses a data access layer under the hood - something the UI doesn't need to know or care about surely?

所以，我的基本问题是:DI 是否要求我将所有下层接口暴露给所有上层，这是好事还是坏事?

So, my fundamental question is: Does DI require that I expose all my lower layer interfaces to all upper layers and is this a good or a bad thing?

谢谢

为了澄清(经过一些评论后)，我知道我的业务对象应该不知道它使用哪个特定的实现(因此在构造函数中注入了依赖项)但是我认为 BO 之上的层不应该知道业务对象甚至需要对 DAL 的依赖.

To clarify (after a few comments), I know my business object should be ignorant of the which specific implementation of which IDataAccess it uses (hence the Dependency being injected in the constructor) but I thought that the layers above the BO should not know that the Business Object even requires a dependency on a DAL.

推荐答案

我认为答案很简单.你的底层(接口、bll、dal、实体)只是一堆 libraries.由客户决定使用哪些库，这将增加客户的灵活性.此外，它们是库，因此任何与应用程序相关的配置(连接字符串、数据缓存等)都位于客户端.那些配置本身，有时也需要注入并包含到 Composition Root 中.

I think the answer is rather simple. Your bottom layers (interface, bll, dal, entities) are just a bunch of libraries. It is up to the client to decide which libraries to be used and it will increase client's flexibility. Moreover they are libraries, so any application-related configurations (connection strings, data caching, etc) lies on the client. Those configuration itself, sometimes also need to be injected and included into Composition Root.

但是，如果您想要统一逻辑而不是客户端的灵活性，您可以选择网络/应用服务作为附加层.

However, if you want to has an uniform logic and not client's flexibility, you can choose web/app services as an additional layer.

1st Layer        Entities

2nd Layer       Interface

3rd Layer       BLL  &  DAL

4th Layer    Web/App Services

5th Layer           UI

这样，您的合成根就存在于一层(第 4 层)中.并添加您的 UI，只需将服务引用添加到第 4 层(如果需要，也可以添加到第 1 层).然而，这又暗示了同样的 Mark Seeman 的文章，分层值得映射.我假设您可以将 app/web service 更改为 Composition Root.

This way, your composition root exists in one layer (4th). And add your UI just need to add service reference to 4th layer (or 1st if needed). However, this implies the same Mark Seeman's article again, layering is worth the mapping. I assume that you can change the app/web service to Composition Root.

此外，这种(应用程序/网络服务)设计有利有弊.优点:

Moreover, this (app/web service) design has pros/cons. Pros:

1. 您的应用已封装

1. Your app is encapsulated

您的应用正在通过应用/网络服务进行桥接.保证您的 UI 不知道 DataAccess，从而满足您的要求.

Your app is being bridged by app/web services. It is guranteed that your UI don't know the DataAccess, thus fulfill your requirements.

您的应用是安全的

简单地说，让 UI 需要访问应用服务在安全方面是一个巨大的收获.

Simply said, having UI need to access app service is a huge gain in security aspect.

访问便携性

现在您的应用可以随处访问.无需依赖dll即可通过第三方应用(其他网站)连接.

Now your app can be accessed everywhere. It can be connected by 3rd party app (other web) without has relying on dlls.

缺点:

1. 服务呼叫期间的间接费用

1. Overhead cost during service call

身份验证、网络连接等都会在webservice调用过程中造成开销.我对性能影响没有经验，但对于高流量应用来说应该足够了.

Authentication, network connection, etc, will cause overhead during webservice call. I'm inexperienced for the performance impact but it should be enough for high traffic app.

客户不灵活

客户端现在需要使用服务而不是普通对象来访问 BLL/服务.

Client now need to access BLL/Services by using services instead of normal objects.

为不同类型的客户提供更多服务

More Service for Different Type of Client

现在您需要提供比需要更多的服务.例如 WebRequestRetriever、MobileRequestRetriever 而不是访问一个单纯的 IRequestRetriever 并让组合根连接其余部分.

Now you need to provide more service than needed. Such as WebRequestRetriever, MobileRequestRetriever instead of accessing to a mere IRequestRetriever and let the composition root wire up the rest.

如果这个回答牵涉到主题，请见谅(完成后才意识到).

Apologize if this answer boarden the topic (just realized after finished).

这篇关于依赖注入 vs 分层架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！