dao 模式和关系
我正在 PHP 中使用 DAO 模式。我理解以这种方式分离模型所带来的好处，但我不明白的是，当您的表通过关联实体相关时，您应该如何构建 DAO 和 VO
我将举一个例子：
在我的数据库中 我是否
USERS(id,username);
USERS_POSTS(id_user(FK),id_post(FK));
POSTS(id, title);
USER_COMMENTS(id_user(Fk),id_post(FK));
COMMENTS(id, text);
创建了 UserVO、PostVO 以及相应的 setter 和 getter，然后 UserDAO 和 PostDAO 负责 SQL最终返回VO。 对这些表中的数据执行 CRUD 操作非常简单，但是当您开始考虑关联表并检索跨不同表的数据时，您就会开始认为使用 DAO 不再那么简单了……
您将如何组织 DAO如果您想返回文章作者的所有评论，请使用pattern？我不需要 SQL 查询，我只是将其作为真实情况的示例...
我读到，为每个关联表配备关联 DAO 和 Vo 是一个好主意。 它的 VO 由什么组成？仅 2 个外键还是来自两个表的所有属性？
如果逻辑是关联实体有 DAO 和 VO，如果查询“遍历”超过 3 个表（使用 2 个关联实体），解决方案是什么？
我怀疑 DAO 模式是否会有名为 users_posts_comments_article 的对象:)））
谢谢
I'm working with DAO pattern in PHP. I understand the benefits that you get from separating your model this way, but what I don't understand is how are you supposed to build DAOs and VOs when your tables are related through associative entity
I'll give an example:
In my DB I have
USERS(id,username);
USERS_POSTS(id_user(FK),id_post(FK));
POSTS(id, title);
USER_COMMENTS(id_user(Fk),id_post(FK));
COMMENTS(id, text);
I create UserVO, PostVO with corresponding setters and getters and then UserDAO and PostDAO in charge of SQLs that in the end return VOs .
Performing CRUD operations on data from these tables is really simple, but when you start thinking about relating tables and retrieving data that's across different tables is when you start thinking that using DAO is not that simple any more...
How would you organize your DAO pattern if you wanted to return all the comments made by the author of article? I don't need SQL query I'm just giving this as an example of real situation...
I read that it would be a good idea to have associative DAO and Vo for every associative table.
What would its VO consist of? Just 2 foreign keys or from all attributes from both tables?
If the logic is having DAO and VO for associative entity what's the solutions if the query goes "through" more than 3 tables (using 2 associative entities)?
I doubt that DAO pattern would have object called users_posts_comments_article :)))
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
作为你自己，你想要获取什么样的数据并编写一个提供该数据的层。不要考虑如何称呼连接两个以上表的类。
您正在考虑将表格转变为模型，但您可能正朝着不适合您的项目的方向前进。由于我不知道你的项目有多大，所以我不能说这是否可以。
以下内容肯定会给您带来一些思考：http://weierophinney。 net/matthew/archives/202-Model-Infrastruct.html
引用那篇文章（他指的是域模型）：
As yourself what kind of data you want to get and write a layer that provides that. Don't think about what to call classes that join more than two tables.
You are thinking about turning your tables into models and you might be heading in a direction that is not appropriate for your project. Since I don't know how big your project is, I can't say whether this would be OK or not.
Here's a read that will definitely give you some food for thought: http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html
Quote from that article (he's referring to Domain Models):
保持简单，s。
DAO 或任何哲学或任何东西只能在一定限度内有意义。
恕我直言，对于像博客这样简单的事情来说这是浪费时间，如果您想要抽象，只需使用简单的 getitem('class',$conditions) 或 get related ($pathandconditions,$itemconditions) 即可。
这类东西肯定涵盖了基本 sql 使用的所有需求。
getUsersWhoHaveAFrigginLongMethodNameofDoom 确实是一个坏主意，定义这种未抽象的过度复制/粘贴的函数直接违背了可维护性等。
Keep it simple, s.
DAO or whatever philosophy or anything can only make sense to a certain limit.
IMHO, this is a waste of time for such a simple thing as a blog, if you want abstraction, just go for simple getitem('class',$conditions) or get related ($pathandconditions,$itemconditions).
That kind of stuff definitely covers all the needs you can have for basic sql use.
The getUsersWhoHaveAFrigginLongMethodNameofDoom is really a bad idea, defining such unabstracted overly copy/pasted functions goes directly against maintainability etc.