简体繁体 English

DAO层应如何实现？一个表DAO还是多个表DAO？

[英]How should a DAO layer be implemented? One table DAO or multiple table DAO?

原文 2019-05-24 08:53:26 6 1 architecture/ dao/ dependency-management/ design-principles/ layered

I am implementing a module as per layered architecture. 我正在按照分层体系结构实现模块。 It will have a presentation layer, service layer, a business layer and a DAO layer. 它将具有表示层，服务层，业务层和DAO层。 As per layered architecture guidelines, the communication flow should be top to bottom. 根据分层体系结构指南，通信流程应自上而下。 Similarly, the dependency should also be top to bottom ie presentation layer - uses -> service layer - uses -> business layer - uses -> DAO layer. 同样，依赖关系也应自上而下，即表示层-使用->服务层-使用->业务层-使用-> DAO层。 ie business layer should not depend on service layer and likewise. 即业务层不应该依赖服务层，同样。

Question 1: 问题1：

What should be the inputs to each layer? 每层的输入应该是什么？ Since, the service layer is called from presentation layer, should the service layer accept UI bean as the input? 由于服务层是从表示层调用的，因此服务层是否应该接受UI Bean作为输入？ or Service Bean as the input ? 还是Service Bean作为输入？ Same for business and DAO layers. 业务层和DAO层相同。

Question 2: 问题2：

Should the DAO layer be per table or can it handle multiple tables (all owned by a single module) ? DAO层应该按表还是可以处理多个表（全部由一个模块拥有）？ The data of my module gets stored in multiple tables. 我模块的数据存储在多个表中。 Since all these tables are owned by a single module, i think it makes sense to have a single DAO layer which abstracts the multi-table storage of the data from upper layers. 由于所有这些表都由单个模块拥有，因此我认为拥有一个DAO层是有意义的，该DAO层从上层抽象出数据的多表存储。 Also, if different implementations of a DAO layer needs to be plugged (database storage, SVN storage etc), it makes sense to have a single implementation plugged (which handles all data). 另外，如果需要插入DAO层的不同实现（数据库存储，SVN存储等），则插入单个实现（处理所有数据）是有意义的。 Also, multiple table DAO would be performance efficient in terms of fetching data ( a single join query would suffice ) 此外，就获取数据而言，多表DAO将具有高效的性能（单个联接查询就足够了）

Question 3: 问题3：

If multiple table DAO design is considered, then the input to the DAO layer would be business bean. 如果考虑多表DAO设计，则DAO层的输入将是业务bean。 It is the responsibility of the DAO layer to convert the business bean to multiple DB beans each representing a table and handling the persistence. DAO层负责将业务Bean转换为多个DB Bean，每个DB Bean代表一个表并处理持久性。 But this would not be compliant with the layered architecture where it says that layers should be isolated and any layer should not depend on its upper layer. 但这与分层架构不兼容，在分层架构中，分层表示各层应该是隔离的，任何层都不应该依赖于其上层。 In this case, the input to DAO layer is business bean (not DB bean) and the conversion from business bean to DB beans and vice-versa is the responsibility of the DAO layer which means it knows how to convert a business bean to DB bean and vice-versa. 在这种情况下，DAO层的输入是业务Bean（不是DB Bean），并且从业务Bean到DB Bean的转换（反之亦然）是DAO层的责任，这意味着它知道如何将业务Bean转换为DB Bean。反之亦然。

Can someone please clarify on the above? 有人可以在上面澄清一下吗？ What should be the proper way to implement such a module? 实现此类模块的正确方法应该是什么？ Is the current implementation as per guidelines? 当前的实施是否按照指南进行？ A proper explanation would help a lot. 适当的解释会很有帮助。 Thanks! 谢谢！

The current implementation I have is 我目前的实现是

Presentation layer: converts UI bean to service bean and passes it to Service layer. 表示层：将UI Bean转换为服务Bean，并将其传递给服务层。
Service layer: converts service bean to business bean and passes it to Business layer. 服务层：将服务bean转换为业务bean，并将其传递给业务层。 Also orchestrates calls between various dependent services. 还协调各种依赖服务之间的呼叫。 Handles transaction boundary. 处理交易边界。 Returns service bean to presentation layer. 将服务bean返回到表示层。
Business layer: passes business bean to DAO layer. 业务层：将业务bean传递到DAO层。 Returns service bean to service layer 将服务bean返回到服务层
DAO layer: Converts business bean to DB beans and vice-versa. DAO层：将业务Bean转换为DB Bean，反之亦然。 Returns business bean to business layer. 将业务Bean返回到业务层。

1 个解决方案

I will use the example of a social network website throughout this answer. 在整个答案中，我将使用社交网络网站的示例。

Your UI should depend on your service, but only unidirectionally. 您的UI应该取决于您的服务，但只能是单向的。 Imagine the case when you have some posts on the UI and you intend to implement the feature of "Like". 想象一下当您在UI上有一些帖子并且打算实现“赞”功能时的情况。 Intuitively, when a user clicks on the Like button for a post, a record in the corresponding table should be created and later shown on the UI. 直观地，当用户单击帖子的“赞”按钮时，应在相应表中创建一条记录，然后在UI上显示该记录。 So, you need a Like feature implemented, which, on the UI means that you have a POST request handler which calls the corresponding method in the service layer, passing the user's ID and the post's ID. 因此，您需要实现一个Like功能，该功能在UI上意味着您有一个POST请求处理程序，该处理程序在服务层中调用相应的方法，并传递用户的ID和帖子的ID。 The service layer should be totally agnostic to the UI and should only handle the session validation and call the corresponding method in the business layer. 服务层应该与UI完全无关，并且应该仅处理会话验证并在业务层中调用相应的方法。 Your business layer should, on its turn handle the logic of your action and ensure that your methods in the DAO layer are being called, so a Like record is created in the database and possibly some other things might happen that you might need. 业务层应依次处理操作的逻辑，并确保调用DAO层中的方法，以便在数据库中创建一个Like记录，并且可能会发生一些您可能需要的其他事情。 When all the DAO methods to be called are successfully executed (if not, then the error will have to be properly handled), the Business layer should respond to the service layer, which, in turn should send the emails to the users to be notified and respond to the UI. 当所有要调用的DAO方法成功执行后（如果未成功执行，则必须正确处理错误），业务层应响应服务层，服务层又应将电子邮件发送给用户以得到通知并响应用户界面。
Beware the dragon called "premature optimization". 当心这条称为“过早优化”的巨龙。 You should have a single DAO layer, because it will largely simplify your life. 您应该有一个DAO层，因为它将大大简化您的生活。 If later you have some performance issues, then you will have to solve them. 如果以后您遇到一些性能问题，则必须解决它们。 However, if you are going to have performance issues, it is highly probable that it will be caused by something else. 但是，如果您将遇到性能问题，则很有可能是由其他原因引起的。 DAO layer means that you have a layer where your DAO is being represented. DAO层意味着您拥有一个表示DAO的层。
See point 2. 见第2点。