函数相关库，还是单个服务层？答案

【问题标题】：Function related libraries, or single service layer?函数相关库，还是单个服务层？
【发布时间】：2017-02-20 02:56:54
【问题描述】：

我和我的团队正在寻找证据来支持类似功能的多库方法，或者将所有这些功能浓缩在单个服务层中。重要的是要注意，这将位于 Web api 之后，并且任何一种方法都是有效的，但我们需要决定哪种方法更有好处。为了说明我们正在查看的层，我们将拥有以下内容：

Solution
    WebAPI
    Services ---- This is what we're looking at
    DataAccess

请记住，如果我们确实使用了多库方法，我们仍然会有一个 Services 项目，但它会更精简并且具有更具体的功能。我们不打算独立部署这些库，但需要在同一个解决方案中引用它们，或者通过 web api 访问它们。

我们其他人会提出如下建议：

Solution
    WebAPI
    Services
    Services.Geography        ---
    Services.Membership       --- This is the alternative approach
    Services.ProductDelivery  ---
    etc...

我们在第一个选项中看到的好处是将所有这些代码组织在一个库中，这样可以更轻松地提取重复代码、潜在的单元测试，并可能从构建过程中减轻一些负担。

选项 2 的好处是项目之间的功能有清晰的划分，具有可在需要时可移植的独立代码，并且通常能够独立处理和配置应用程序的不同方面。

我们在选项一中看到的缺点是服务层现在负责应用程序的每个方面，这会使库膨胀，并且在我看来有点违反单一职责。我们意识到该规则并不像方法和类那样适用于库，但似乎通过分离功能还有其他好处。也有可能错误地将代码放置在不属于它的地方，或者在可能不适用的地方使用可用于整个项目的类。

选项 2 的缺点是明显增加了项目构建的开销，在配置中工作（即使这可能是可取的）并且可能会使解决方案因过多的项目而变得混乱。我认为我们计划将类似的功能整合到单个项目中（即，我们可能会在该项目中构建 ProductDelivery 的多个实现，以便能够在它们之间切换或出于不同原因使用不同的实现）。

我们意识到我们所有的业务规则都可以用任何一种方法来完成，我们只是在决定哪种方法是更好的实践方面陷入僵局。

所以问题是，这两种方法中哪一种更好？

【问题讨论】：

标签： c# .net architecture n-tier-architecture

【解决方案1】：

我有两件事可以让我想到选择第一个选项：

您的服务仅使用一个数据层库。
您的服务真的很短（就像只实现 CRUD）

在库中拆分，一个在整个库中只计算几行的类，可能会很尴尬。除非，你知道之后它会增长很多（当然是在几个课程中）。

如果不是，我会说选项 2 更好，因为：

这样替换服务的一部分会更容易。更改所需的库，就完成了。
如果你想避免每个库之间的强耦合，它应该更抽象
应该更容易测试它的特定部分。
它应该更具可配置性，您可以在引用所有这些的项目中配置所有它们（即使一个或多个库没有改变很多东西）。
应该不像神库
对于其他一些项目，它可能更易于导出，具体取决于您的库的专业程度。

对于以下几点，我不同意：

允许更轻松地提取重复代码的单个库

如果您小心，您的重复代码可以提取到所有其他人共有的父库中。因此，您所有的重复代码都应该被自动提取（除非缺乏沟通或人们更喜欢复制/粘贴代码。但是，一个库不会改变这一点。甚至可能更难找到代码已经存在的位置)。

潜在的单元测试

为什么有几个库必须更难测试？如果您有多个库，则必须使它们更加抽象，以允许更改。然后，您的测试应该很容易。

也许从构建过程中得到一些缓解。

为什么？如果您所有的库都命名良好，那么您的问题在哪里？部署一个或多个 dll 应该没那么难。
如果是关于配置，一个或多个库，您仍然需要进行相同的配置，不一定要更多（但可能更多）。

我也不同意单一责任不适用于图书馆。它是。每个图书馆，应该负责一项业务，而不是全部。如果你完成了一组库，它可以成为一个框架。甚至，对于一个框架，你将完成一个单一的责任，但比方法、类、库等的责任更普遍......

但您可能需要比我更高级的架构师/开发人员的意见。

如果有人不同意我的观点，请不要犹豫，评论我的回答。我很乐意从您的知识中学习

【讨论】：

目前的计划是有一个单一的数据层。我们许多潜在的其他库将是第三方 api 包装器，它们不一定需要与数据库交互。那些这样做的人可能有自己的数据层，可能会或可能不会与同一数据库或独立数据库交互。我认为这样做会使它们自给自足，并且能够在没有其他解决方案的情况下存在。仍然不能完全确定这是否是我们想要采取的方法。
你使用依赖注入吗？
是的，我们这样做了，StructureMap 作为我们的 IoC 依赖解析器

【解决方案2】：

考虑到我第一个答案中的 cmets。

目前的计划是有一个单一的数据层。我们的许多潜力其他库将是第三方 api 包装器，而不是必然需要与数据库交互。那些可以可能有自己的数据层，可能会或可能不会交互同一个数据库或独立数据库。我认为这样做使它们自成一体并且能够在没有其余部分的情况下存在解决方案。仍然不完全确定这是否是我们想要的方法不过还是拿走吧。

依赖注入？

StructureMap 作为我们的 IoC 依赖解析器

你最终会得到几个库，除非你使用的所有库都必须一起使用。

您将让您的服务成为第三方库的代理，或者您的服务将使用第三方库的代理。

但是无论如何，代理部分不应该在同一个库中。如果您这样做，更改第三方库会更难。

如果您选择的解决方案是您的服务使用第三方库的代理。由于依赖注入，您可以轻松地将这些代理注入到您的服务中。如果你更改第三方库，更改代理实现并更改注入，就可以了。

但是，如果您选择让您的服务成为代理。几乎一样，但你少了一层。并且您的服务实现必须导出到不同的库中。在更改服务时，您还必须更加小心，因为您最终会破坏应用程序中的其他地方。对于最后一点，目前对我来说，让您的服务使用代理层听起来更好。

我还在想。我想它会有更多的修改

【讨论】：

所以我想困境是我们中的一些人想要创建第三方库，其余的人想要将所有功能滚动到组织到不同名称空间的服务层中，所以基本上没有真正的代理了。出于讨论的原因，我个人支持使用库，并且如果所有内容都存在于单个服务/业务层中，而 API 和业务层之间没有代理，则更有可能出现问题。
那些认为一个图书馆会更好的人的论点是什么？多个命名空间不是一个有效点，因为您可以将这些命名空间与不同的库一起使用，但它们之间的“耦合”较少。
可扩展性不是问题，拥有太多库会在维护和构建过程中产生不必要或不适当的开销。拥有太多的库也会给开发人员带来风险，他们会错误地在项目之间创建他们不应该的引用。测试不会变得更难，并且更容易确定哪些其他库正在使用一个库中的代码，而不是多个库，这使得确定依赖关系变得更加困难。
我们确实有其他项目/解决方案，我们过去使用不太理想的构建和部署过程部署了其中一些库，我们正试图将其中的许多压缩成一个解决方案，因此我们不会在部署更改之前不知道我们正在影响哪些消费者。我认为这是一个不同的问题，与我们试图做出的决定没有任何关系。不管有一个库还是多个业务逻辑库，我们仍然会有其他项目。
我明白了。我同意引用过多可能是个问题。但我仍然认为它可以支持更容易的进化，而不是单一的进化。但最后的问题是，有多少服务依赖于同一个第三方库？因为，在这种情况下，您可以将使用同一第三方的所有服务重新组合在一起，并将其他服务拆分为另一个。像这样，如果你改变了一个第三方，你只改变了使用它的服务（在同一个库中）。它是一种混合解决方案，介于单个库和多个库之间。