Tag: 多层

最佳实践 – 多层架构和DTO

在stackoverflow上阅读了一些Q / As之后，我仍然对在我的Web应用程序中正确实现DTO感到困惑。 我当前的实现是一个（基于Java EE的）多层体系结构（具有持久性，服务和表示层），但是所有层都使用“公共”包，包含（以及其他）域对象。 在这种情况下，层不能真正被认为是独立的。 我打算逐步删除常见的包，但我遇到了各种挑战/问题： 假设持久层将使用类myproject.persistence.domain.UserEntity （基于JPA的实体）来存储数据库或从数据库加载数据。 要在视图中显示数据，我将提供另一个类myproject.service.domain.User 。 我在哪里转换它们？ 用户的服务是否负责在两个类之间进行转换？ 这真的有助于改善耦合吗？ User类应该如何？ 它应该只包含不可变的getter吗？ 编辑现有用户的视图（创建新用户 ，使用现有用户对象的getter等）不是很麻烦吗？ 我应该使用相同的DTO类（ 用户 ）向服务发送请求以修改现有用户/创建新用户还是应该实现其他类？ 通过使用myproject.service.domain中的所有DTO，表示层不会非常依赖于服务层吗？ 如何处理我自己的例外？ 我的当前方法重新抛出大多数“严重”exception，直到它们由表示层处理（通常记录它们并且用户被告知出现了问题）。 一方面我有一个问题，我再次hava共享包。 另一方面，我仍然不确定这可以被视为“最佳实践”。 有任何想法吗？ 谢谢你的任何答案。

三层架构和例外

对于每个应用程序层（例如PresentationException ， ServiceException ， PersistenceException等）都有一个例外，这被认为是一种好习惯。 但是，如果我的服务层直接调用DAO方法（持久层方法）而不需要额外的操作，那该怎么办呢？ 喜欢这个： public class MyService { private IPersonDAO dao = new PersonDAO(); public void deletePerson(int id) { dao.deletePerson(id); } } 我应该使用try-catch块包装此DAO方法调用并重新抛出可能的exception作为ServiceException吗？ 每个DAO方法应该只抛出PersistenceException吗？