design-patterns - 服务层与辅助对象？

Question

我想听听您对具体案例的意见。这是关于服务层与辅助对象的——我不是在寻找理想主义的模式，而只是很好地理解我亲爱的编程同事对此的看法:

在我当前的应用程序中，我有一个完整的域模型(Linq to Sql，非常轻量级的存储库，然后使用跨 IQueryable<> 的扩展方法来根据业务需求进行过滤/排序/排序)，然后是一个包含基于分组的服务的服务层职责，例如 IRegistrationService(注册用户，检查登录名的可用性等)

现在警告。我还有一些“助手”类，它们可以做加密之类的事情，而且我还在该目录中填充了其他不可分组的元素(例如自定义枚举等)

我现在需要创建一个新类，它将为我的应用程序处理自定义链接的生成，这仅比 String.Format 具有不同的对象并考虑到它们的属性。内部运作无关紧要。但是，我很难实例化某种“LinkService”，现在它会做到这一点——我觉得当我完成后，我最终会得到 100 个服务(以及它们的接口(interface) + 实现)。

同时，我不想在我的“Helpers”命名空间/目录(例如 LinkManager)中创建一些松散的类和其他东西的组合。

该怎么办？你们把仍然有点业务层级别的东西放在哪里，但同时你如何限制业务/服务层中的项目数量？您将所有这些小助手类放在哪里，例如简化和管理 session 访问的中间对象(我假设您希望拥有这种强类型 - 至少我这样做)？

让我知道你的想法？谢谢 !

Answer 1

对我来说，使用正确的工具来完成工作是关键。如果您需要某种工具来生成链接，这基本上是实体属性到格式化字符串的映射，那么请编写一个工具来执行此操作。它不一定是服务......相反，为类似的东西提供完整的服务可能是矫枉过正。但是，我不会将其归为您的一般“ helper ”。听起来这是有特定目的和意图的东西，背后有特定的行为。因此，将其放在适合该行为的位置……即使那是一个新项目。

我尽量不在我的应用程序中有一大堆“通用”代码。一切都有目的并实现特定的行为。有时，这种目的和行为是高度可重用的，但我仍然尝试在逻辑上组织我的领域的那些可重用元素。从高层次来看，我看到我的大部分应用程序分为以下几类:

客户

API/服务

域名

数据访问(可选)

框架

很多这种可重用的功能都属于框架和领域之间的一个下层区域。它的一部分可能作为一些基类和/或接口(interface)以及框架中的支持类型存在，另一半是具体的实现，驻留在我的域中。有时看起来很奇怪，但以这种方式组织它可以帮助我保持我的域尽可能干净(专注于业务问题)，同时仍然允许我将常见和可重用的概念抽象为较低级别的“框架”类型。