程序设计 - 按功能打包还是按层打包? [英] Program Design - Package by Feature vs. Layer or Both?

查看:19
本文介绍了程序设计 - 按功能打包还是按层打包?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正处于 Web 应用程序的设计阶段,该应用程序允许用户创建工作请求,而工作人员可以针对这些请求安排时间.该应用程序还将为主管提供报告功能,以获取每日总计、报告和所花费时间的帐户,即成本分配".

I am in the design stage of a web application that allows users to create requests of work and the workers to put time against those requests. The application will also have reporting capabilities for supervisors to get daily totals, reports, and account for time spent, "cost allocation".

我过去处理的应用程序是使用逐层封装的方法设计的.我认为通过功能设计使用包会更有效,我对此设计有疑问.

Applications I've worked on in the past have been designed using the package by layer approach. I'm thinking it would be more efficient to use a package by feature design and I have a question about this design.

我目前对功能包的想法:

What I am currently thinking for the packages by feature:

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

前端将是 Tomcat 服务器和 JSP.而且,后端将是一个 Oracle 数据库,EclipseLink 负责持久化.

The front-end will be Tomcat server and JSP. And, the back-end will be an Oracle database with EclipseLink doing the persistence.

我的问题:

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

In my understanding of package by feature, the entities and DAOs would go into the package associated with them. Spreading out the persistence layer across several packages. Leaving packages to call entities from other packages. With all of the overlap is this really functional? There would be no isolation between the packages. What are the pros and cons to using package by feature? Would it be good design to go with an additional persistence layer? Or, do I have the understanding of this totally wrong?

推荐答案

我建议开始基于业务实体打包事物.在那里你可以根据层次划分事物.

I would suggest to start package things based on business entities. And in there you can divide things based on layers.

所有的重叠是真的功能?

With all of the overlap is this really functional?

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

I am practising it for long. I don't see any major issues with this approach. You must find out what to decouple and how much it should be decoupled. For example, calling a persistent method of orders from a customer package using the API provided by orders is pretty fine for me.

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

What are the pros and cons to using package by feature?

我发现它比严格的面向层的包装更简单、直接、易懂且易于使用.当您想要将事物拆分并分发到不同的地方时,它会受益匪浅.

I find it more simple, straight, understandable and easy to work with than strict layer oriented packaging. It benefits when you want to split and distribute things to different places.

搭配一个好的设计会吗?额外的持久层?

Would it be good design to go with an additional persistence layer?

看看这个 SO 线程,我找到了 JPA,或者同样,不要鼓励 DAO 模式.

Look at this SO thread, I found JPA, or alike, don't encourage DAO pattern.

进一步阅读

这篇关于程序设计 - 按功能打包还是按层打包?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆