程序设计 - 按功能与层或两者打包？答案

【问题标题】：Program Design - Package by Feature vs. Layer or Both?程序设计 - 按功能与层或两者打包？
【发布时间】：2011-09-09 18:12:28
【问题描述】：

我正处于 Web 应用程序的设计阶段，该应用程序允许用户创建工作请求，并且工作人员可以将时间用于处理这些请求。该应用程序还将为主管提供报告功能，以获取每日总计、报告并说明所花费的时间，即“成本分配”。

我过去开发的应用程序都是使用逐层封装的方法设计的。我认为按功能设计使用包会更有效，我对此设计有疑问。

我目前按功能考虑的软件包：

前端将是 Tomcat 服务器和 JSP。而且，后端将是一个由 EclipseLink 进行持久化的 Oracle 数据库。

我的问题：

在我对逐个功能包的理解中，实体和 DAO 将进入与其关联的包中。将持久层分布在多个包中。离开包来调用其他包中的实体。有了所有的重叠，这真的有用吗？包之间不会有隔离。按功能使用包的优点和缺点是什么？使用额外的持久层会是好的设计吗？或者，我对此的理解完全错误？

【问题讨论】：

【解决方案1】：

5 年后...

（背景中的悬疑音乐）

想象一下这种荒谬的情况：

经理公司、程序员公司、人力资源公司和营销公司，其中程序员公司只有程序员，没有经理、营销人员或人力资源；

我们不希望按专业划分同事，而不是组织（自我协调）团队，或者我们会吗？

将东西打包在一起，而不是根据它的作用，只会让你跳到你要找的地方 10 次。

现在看起来不是很性感吗？通过查看结构，您已经可以了解应用程序的全部内容。不满意？ Read full article.

【讨论】：

【解决方案2】：

我建议开始根据业务实体打包东西。在那里你可以根据层划分事物。

所有的重叠是真的吗实用？

我练习了很长时间。我认为这种方法没有任何重大问题。您必须找出要解耦的内容以及应该解耦的程度。例如，使用orders 提供的API 从customer 包中调用orders 的持久化方法对我来说非常好。

使用的优缺点是什么按功能打包？

我发现它比严格的面向层的包装更简单、直接、易于理解和易于使用。当您想将东西拆分并分发到不同的地方时，它会很有用。

搭配一个很好的设计额外的持久层？

进一步阅读

【讨论】：

我明白你的意思。我曾考虑过摆脱 DAO 层，但遇到了如何做的问题。在 Eric Evans 的 DDD 一书中，他谈到了使用存储库模式。这是否提供了与 DAO 类似的功能？我仍在掌握这些概念，所以请原谅我的菜鸟。另外，是否有一个很好的代码示例可以更好地了解 DDD？
@Miller：是的，有点类似。客户端使用表达式 API 或以声明方式创建查询并将其传递到存储库以获得满意。您可以将 JPA 视为 DAO 层，正如我提供的线程中所建议的那样。
那么实体管理器将被注入存储库，对吗？这将允许该层的 JPA 功能。
@Miller：实体管理器将被注入到您的业务组件中，并作为您的业务组件的存储库。将 JPA 视为存储库模式的实现。此外，我在上面的原始答案中添加了一个链接。
@AdeelAnsari 你有一些手册和参考链接来演示如何根据业务实体打包东西？

【解决方案3】：

如果我要在按功能包和按层包的两个包之间进行选择。我会逐层选择包。

出于多种原因，

但要回答您的问题，功能与层或两者兼而有之，我会说两者，主要按层打包，然后按功能打包。

【讨论】：

所有功能中使用的实体怎么样？示例：请求是 Requests 包中的 CRUD。然后，它们用于在工作时间中设置时间并在成本分配中进行报告。我假设它们将在 Requests 包中的所有查找表中定义一次，并用作其他包中的对象。然后将查找代码放在其他包将使用的 Requests 包中吗？
对于跨层使用的实体，我会考虑使用一个“框架”包，它本身不提供功能，但可以跨层重用通用代码。
喜欢域包？其中将是请求、工作时间对象以及查找表实体？还是我没有抓住重点？
@Miller - 我不明白。您的论点虽然有效，但似乎恰恰反对按功能包装，而不是按层包装（这是 hhafez 所提倡的）。