BusinessLayer的组织服务答案

【问题标题】：Organizing service of BusinessLayerBusinessLayer的组织服务
【发布时间】：2015-05-29 04:58:46
【问题描述】：

目前正在考虑在业务层实现服务的策略。我的第一种方法是为每个类实现一个服务功能，但是功能的数量最终会增长并且变得难以从表示层调用，因为 id 必须记住它们（大量的类）。相反的选择是让一个类实现所有服务，这将创建一个巨大的文件。

我已经看到在每个类（ProductBLL 或 CompanyBLL）中实现功能（方法）的实现，这将使服务更易于管理，但是有些服务（例如“getmeProductsAndCompanies”）似乎并不常见既不属于 ProductBLL 也不属于 CompanyBLL。

我的问题是：创建一个类 AplicationService 是否是个好主意，它每个 Service 都有一个方法来实例化正确的 ServiceClass 和正确的方法？我的目标是在 PL AplicationService 中实例化 as 和 as.getmeProductsAndCompanies()

到目前为止，我通过的互联网资料有非常理论或非常复杂的解决方案。我也愿意接受建议。

【问题讨论】：

标签： c# entity-framework architecture 3-tier

【解决方案1】：

使用composite pattern。基本上，您可以创建尽可能多的小类/函数。然后这些部分将被更大的类/函数调用。那么更大的类也可以被更大的类再次使用。

【讨论】：

我认为您的想法与 FractalizeR 相同，只是没有接受您的答案，因为我认为复合模式专注于制作派生为 B 和 C 的对象 A，然后说 C 可以也是一个 A，因此是形状示例的常见用法。

【解决方案2】：

我的第一个方法是为每个类实现一个服务功能，但功能的数量最终会增长并变得困难从表示层调用，因为 id 必须记住它们（大量类）

我不认为将所有服务聚合到一个外观中会有所帮助。它只会使他们复杂化。请考虑构建服务并为它们设计一些命名模式。

例如，您有 OrderService 对订单执行所有操作（名称选择错误，顺便说一句；））。最终它变得太大，当这种情况发生时，你必须将它一分为二。拆分时，必须使用函数式命名。服务的名称必须回答“该服务具体做什么以及使用什么类型的数据”的问题。例如，OrderDisplayService 对我来说是个不错的选择。

当你必须找出你需要注入到你的调控器实体（MVC-like控制器，通常）中的服务时，你必须首先输入服务命名空间名称（\Acme\Services\），然后输入你想要处理的对象名称（ Order)，然后输入一个动词，描述你想用它做什么 (Display)，然后按下你的 IDE 自动完成按钮。您将有一个相对较短的服务列表，可用于注入（我想您为此使用了一些 IoC 容器）。

将服务拆分为层或单元，以便在 IDE 中工作时，在当前展开的目录中只能看到功能完整的部分

【讨论】：