我想就具体案件征求您的意见。这是关于服务层与帮助对象 - 我不是在寻找理想主义模式，而只是对我亲爱的编程同事对此的看法有很好的理解：
在我当前的应用程序中，我有一个完整的域模型（Linq到Sql，非常轻量级的存储库，然后使用IQueryable＆lt;＆gt;的扩展方法根据业务需求过滤/排序/排序），然后是一个包含的服务层基于职责分组的服务，例如IRegistrationService（注册用户，检查登录名的可用性等）。
现在警告。我还有一些“Helper”类可以执行加密等操作，而且我还在该目录中填充了其他不可分组的元素（例如自定义枚举等）。
我现在需要创建一个新类，它将处理我的应用程序的自定义链接的生成，它几乎不包含具有不同对象的String.Format并考虑其属性。内部运作是无关紧要的。但是，我很难实例化某种“LinkService”，现在就这样做了 - 当我完成时，我觉得我最终会得到100个服务（以及它们的接口+实现）。
与此同时，我不想在我的“Helpers”命名空间/目录（例如LinkManager）中创建一些松散的类和其他内容。
怎么办？你们在哪里放置的东西仍然有点商业层次，但同时你如何限制业务/服务层中的项目数量？你在哪里坚持所有那些小助手类，比如简化和管理会话访问的中间对象（我假设你想要强烈输入这个 - 至少我这样做了？）
让我知道你的想法？谢谢！
答案 0 :(得分：3)
对我来说，使用合适的工具是关键。如果您需要某种工具来生成链接，这基本上是实体属性到格式化字符串的映射，那么请编写一个工具来执行此操作。它不一定是一项服务......相反，为这样的事情提供全面的服务可能是过度的。但是，我不会把它归结为你的一般“助手”。听起来这是具有特定目的和意图的东西，背后有一种特定的行为。因此，将它放在适合该行为的位置......即使这是一个新项目。
我尽量不在我的应用程序中有大量的“通用”代码。一切都有目的并实现特定的行为。有时，目的和行为是高度可重用的，但我仍然尝试逻辑地组织我的域的可重用元素。从较高的层面来看，我认为我的大多数应用程序分为以下几种：
很多这种可重用的功能属于Framework和Domain之间的较弱区域。它的一部分可能作为一些基类和/或接口以及Framework中的支持类型存在，另一半是具体实现，驻留在我的Domain中。它有时看起来很奇怪，但是以这种方式组织它可以帮助我保持我的域尽可能干净（专注于业务问题），同时仍允许我将常见和可重用的概念抽象为较低级别的“框架”类型。