我已经安静地阅读了很多关于该主题的内容，但仍有一些悬而未决的问题。想象以下场景。
[表现层]
您想开发一个具有两个访问点的应用程序：
- Web 前端（基于视图 + 控制器）
- 服务接口
因此，将业务逻辑与这些不同的表示视图分开以供重用是完全有道理的。
[数据层]
在分层架构的另一端，我们有数据层：
- 域/模型对象来表示一些ORM框架映射的数据
- 提供创建、读取、更新、删除（crud）功能的数据访问对象（dao）
这一层是关于访问您的数据的。将所有数据访问特定逻辑保留在该层中，以便可以轻松地被另一个存储系统替换。
[服务层]
这是所有业务逻辑发生的数据层和表示层之间的层。
一方面我不希望这个线程是特定于语言或框架的，另一方面我想知道如何通过中央事务处理（回滚、提交）来实现它。因此，假设我们使用 spring 作为事务管理的便捷框架。
1. 处理交易的最佳地点在哪里？？？
显然它不是数据访问对象的一部分，因为您想在一个事务中访问和更改多个对象。因此，事务处理必须按照 Spring 框架的建议应用于服务级别。
但是假设您的业务逻辑执行以下操作：
- a) 从数据库请求一些对象
- b) 请求有关这些对象的一些远程信息
- c) 更新数据库中对象的状态
由于操作 b 可能需要未定义的时间长度，因此您不希望在此操作上跨越事务，因为它会分配宝贵的系统资源。因此，必须将一些业务逻辑与其他业务逻辑分开。
这是否意味着服务层必须分成两层，一层是事务性的，一层不是？
2. 如何修改和检索数据？？？
为了呈现数据，表示层必须知道域对象。通过使用 daos，服务层将这些对象的访问权限授予表示层。我看到这种方法有两个问题。
a) 假设 hibernate 被用作一个方便的 ORM 框架。然后依赖项被延迟加载，这对于大多数其他 ORM 框架也是如此。所以我试图访问我的复杂对象的视图代码可能会得到一些延迟加载异常，因为事务上下文已被服务层结束。
处理这种情况的正确方法是什么？？？
b) 控制器通常使用一些框架魔法将 Web 表单中所做的更改直接应用于我的模型对象。这又在任何事务上下文之外，这意味着服务层必须提供将模型对象重新附加到新事务并保存它们的功能。
这真的是正确的方法吗？？？
期待您的回答...