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

Question

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

过去我曾经使用的应用程序是使用逐层方法设计的。我认为通过功能设计使用包会更有效，我对这个设计有疑问。

我目前正在考虑按功能打包的方法：

1. 请求 - CRUD请求，然后分配，添加发票号等......
2. 工作时间 - 用户针对请求，假期，培训或会议的CRUD每日时间
3. 成本分配 - 创建报告，核算会计师想要的东西......

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

我的问题：

在我对按功能分组的理解中，实体和DAO将进入与它们相关联的包。在多个包中展开持久层。将包从其他包中调用实体。所有的重叠是否真的有用？包之间没有隔离。使用打包功能有什么优缺点？使用额外的持久层是否是一个好的设计？或者，我是否完全理解这一点？

Answer 1

我建议根据业务实体启动包装。在那里你可以根据图层划分事物。

  

所有重叠都是真的   功能

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

  

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

我认为它比严格的层面包装更简单，直观，易懂和易于使用。当您想要将事物拆分并分配到不同的地方时，它会受益。

  

与它合作是不是一个好的设计   额外的持久层？

看看这个SO帖子，I found JPA, or alike, don't encourage DAO pattern。

进一步阅读

• Generic Repository and DDD

Answer 2

5年后......

（悬疑音乐在后台）

  

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

     

经理公司，程序员公司，人力资源公司和营销公司，程序员公司只有程序员，没有经理，市场营销人员或人力资源;

我们不希望通过他们的职业而不是组织（自我协调）团队来分裂同事，或者我们会不会？

  

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

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

Answer 3

如果我按功能逐层选择两个包。我会逐层选择。

由于某些原因，

• 在分层结构中，应在各层之间明确定义接口/依赖关系，如果您正在引入不想要的依赖关系，那么适当的包装将很快突出显示
• 它从一个层中隔离一个层中的依赖关系（例如使用Oracle的持久性）。
• 我觉得单独考虑每一层更清晰

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