【发布时间】：2012-01-14 06:27:16
【问题描述】：
也许这对你来说是显而易见的。我是java新手（半年工作），我和我的同事讨论过。我很难根据他们的职责命名我的班级。为此，我的班级获得了他们不应该承担的责任。
你能帮帮我吗？
顺便说一句：我目前在一个项目中工作，我必须使用服务类中的持久层。我已将包拆分为模型、服务和持久性。
【问题讨论】：
标签： java model-view-controller architecture naming-conventions
【发布时间】：2012-01-14 06:27:16
【问题描述】：
命名约定请阅读官方convention。
Manager - 顾名思义，它管理代码中的事物，如 EntityManager，它管理实体，TransactionManager - 它管理事务。所以你可以有一个叫做 SecurityManager 的东西，它管理哪个 Algo 用于加密等
控制器 - 再次，名称说明了很多，控制需要做什么，或者如何做事情。例如ActionController - 负责接收用户操作事件时要做什么
服务 - 将其视为类似 postalService 的东西，由某人在一般注释上执行的任务，您可以使用它。
打包代码需要深思熟虑，您的应用程序打包应始终与其所服务的业务模型保持一致。
除了业务模型之外，您还需要考虑该功能是否是应用程序的核心，以便将其移至核心，例如该功能是否用于与其他应用程序通信，您希望将其移至集成下等等。
【讨论】：
-
对于约定，应该提到的是，坚持您的业务约定而不是 Sun 的约定更好。 Sun 的指导方针当然是一个很好的起点，但最终，您的同事将维护您的代码（最终您将维护他们的代码），因此您应该遵循您公司的惯例（如果您有这样的惯例..）。
-
同意，但您公司的编码标准肯定或多或少会遵循 sun ;)
-
我希望你说的是真的 ;) 但我想我们可以在挖掘最疯狂的编码标准时获得一些乐趣。
-
不再支持官方约定，请参阅 Oracle 的免责声明oracle.com/technetwork/java/codeconvtoc-136057.html
-
该约定与 OP 的要求无关。
为了补充已经给出的好答案，如果您发现很难为您的课程找到合适的名称，那么也许您应该调查您的课程是否有多个职责。如果是这种情况，那么您绝对应该重构代码以将职责隔离到单独的类中。
【讨论】：
这些术语背后有一定的模式和指导方针，我通常以此为基础：
Controller 基于Model-View-Controller design 模式，应明确用于基于此设计模式实现控制器功能的类。例如。如果您使用的是 Spring MVC 并且您从 Controller 类之一进行扩展。
Service 不太具体，但我建议基于 "Patterns of Enterprise Application Architecture" 中的 Service Layer 模式实现。基本上，控制器更特定于平台（例如通过 HTTP 传输和呈现的超文本，通常是基于 Web 的控制器的 HTML）服务不应该知道谁在使用它以及如何使用它。您只是提供一个统一的界面，例如 Web 控制器可以依次使用。
经理嗯...管理东西。连接、应用程序上下文、会话；通常作为整个应用程序的组件可以与之通信的中心位置。
【讨论】：
我不知道我是否曾指定过班级经理，所以我将其省略。
对我来说，controller 是控制或决定某物（信号、消息、..）应该去哪里的东西。
服务是一个接口（以及该接口的实现），通常在系统或子系统的边界提供一些功能。尽可能隐藏实现细节。
【讨论】：
-
避免在类名中使用“manager”的秘诀是什么？
-
@MichaelOzeryansky 我认为海报的意思是无需卸载到第 3 方功能来处理。经理通常是一个类，它有另一个子类来执行所需的服务或逻辑。因此，如果您直接访问（即没有额外的分离层），您可以绕过它的使用。 （将逻辑和服务直接捆绑到核心功能中将不再需要管理器）。
-
@user3681384 我最常见的管理器用例是将一些服务组合到一个函数调用中。我没有每次都进行这种组合，而是在管理器中定义了该功能。管理器也可以用所有服务之间使用的公共属性来实例化。但是帖子说“我不知道我是否曾经任命过班级经理”，所以我专门询问了这一点。通过将其命名为“控制器”来避免将其命名为“经理”并不能避免问题。
-
不，我倾向于避免使用“经理”一词，因为它太模糊了。我可能会将它用于一个类，该类的实例应该关心资源的分配，甚至它们的生命周期或对它们的访问。这不会经常发生我需要这样的东西。只是组合一些调用不值得一个特殊的名字，称它为 manager 也不合适——至于设计模式听起来最像一个门面。