管理人/交易的目的是什么？
我第一次构建 Spring 应用程序。我遇到了很多并发问题，我怀疑我管理后端的方式有问题。我可以看到我的后端代码和我见过的示例之间的唯一区别是管理器类。
在我的代码中，我有我的模型（由 hibernate 管理）和我的 DAO，用于在模型上执行 CRUD/搜索等。在我看过的示例代码中，他们从不直接使用 DAO。相反，他们使用间接调用 DAO 的管理器类。对我来说，这似乎是毫无意义的代码重复。
这些经理课程有什么用？我读到他们将我的代码包装在“事务”中，但我为什么要这样呢？
I'm building a spring application for the first time. I'm running into lots of problems with concurrency, and I suspect that there is something wrong with the way I'm managing the backend. The only difference I can see between my backend code and examples I've seen are manager classes.
In my code, I have my model (managed by hibernate) and my DAOs on top of that to do CRUD/searching/etc on the models. In example code I have looked at, they never use the DAO directly. Instead, they use manager classes that call the DAOs indirectly. To me, this just seems like pointless code duplication.
What are these manager classes for? I've read that they wrap my code in "transactions," but why would I want that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
事务用于使更新成为“事务性”的。
示例）用户单击一个网页，导致数据库中更新 13 条记录。事务将确保 0 或 13 个更新通过，错误将使其全部回滚。
管理者必须让事情变得更容易做。它们不会神奇地使您的代码线程安全。直接使用 DAO 本身并不是线程安全错误。
但是，我建议您限制 DAO 中的逻辑，并在业务层中放置尽可能多的逻辑。请参阅DAO 模式的最佳实践？
如果您发布了一个代码的小示例，不能很好地处理多线程，我们可以提出一些想法......但事务或管理器本身都无法解决您的问题。
Transactions are used to make updates "transactional".
Example) A user clicks a webpage that leads to 13 records being updated in the database. A transaction would ensure either 0 or 13 of the updates go through, an error would make it all roll back.
Managers have to do with making things easier to do. They will not magically make your code threadsafe. Using a DAO directly is not a thread safety bug in and of itself.
However, I suggest you limit the logic in your DAO, and put as much logic as you can in the business layers. See Best practice for DAO pattern?
If you post maybe a small example of your code that isn't working well with multiple threads, we can suggest some ideas... but neither transactions nor managers alone will fix your problem.
许多应用程序都有重要的需求，并且业务逻辑通常涉及对多个资源（例如多个 DAO）的访问、这些访问的协调以及跨这些访问的事务控制（如果您访问 DAO1 和 DAO2，您希望提交或回滚更改，如下所示）一个不可分割的工作单元）。
因此，通常将这种复杂性封装并隐藏在专用的服务组件中，以粗粒度的方式向客户端公开业务行为。
这正是您所指的管理器正在做的事情，它们构成了服务层。
Many applications have non trivial requirements and the business logic often involves access to several resources (e.g. several DAOs), coordination of these accesses and control of transaction across these accesses (if you access DAO1 and DAO2, you want to commit or rollback the changes as an indivisible unit of work).
It is thus typical to encapsulate and hide this complexity in dedicated services components exposing business behavior in a coarse-grained manner to the clients.
And this is precisely what the managers you are referring to are doing, they constitute the Service Layer.
DAO 不应该拥有交易，因为它们无法知道它们是否只是更大交易的一部分。
服务层是事务所属的层。你说它们是“毫无意义的代码重复”是错误的。
DAOs should not own transactions, because they have no way of knowing whether or not they're only a part of a larger transaction.
The service tier is where transactions belong. You're incorrect to say they're a "pointless code duplication."