DTO等的设计问题

发布于 2024-08-13 06:07:57 字数 346 浏览 1 评论 0原文

我正在用 C# 设计一个 Web 应用程序,主要与数据库进行交互。我为数据库中的每个表创建了一个 DTO。现在,对于每个表,都有一个自定义表存储库类,用于执行与该特定表相关的所有保存和获取操作,并且我正在使用存储过程。

现在的问题是一些存储过程实际上会执行内部联接操作,然后发送一个自定义输出,该输出是 2 个表的组合。

因此我无法将数据存储在单个 DTO 对象中。

如果有任何基本操作主要在单个表上完成,那么一切都很好。我可以调用表 dto 对象来插入和从数据库中获取。 但是,当存储过程中存在联接时,并且在某些情况下,我们会更新多个表。

我们应该如何设计应用程序?

请帮忙

谢谢

I am designing a web application in c# that mostly talks with the database. I have created a DTO for each table in the database. Now for each Table there is a custom table repository class that does all the saving and fetching pertaining to that particular table, and I'm using stored procedures for that.

The issue is now some stored procedures will actually do a inner join operation and then send a custom output which is a combination of 2 tables.

Therefore I'm not able to store the data in a single DTO object.

If there are any basic operations which are mostly done on a single table then things are fine.. I can call the table dto object for both inserts and fetching from the database.
But when joins are there in stored procedures and during certain situations we update multiple tables.

How should we design the app?

Please Help

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

我是有多爱你 2024-08-20 06:07:57

听起来您可能需要重新考虑拥有一个直接对应于数据库中每个表的 DTO。

相反,DTO 应该对应于网站背后使用的现实世界模型中的逻辑。因此,例如,客户对象中可能包含订单 ID 的集合,即使这些在逻辑上存储在数据库中的两个表中。

让 DTO 引用其他 DTO 并没有什么问题(事实上这通常是必要的),因此,例如您可以有一个指向 Address 类列表的 Customer 类。

如果事情变得更加复杂,您很可能会考虑在此时引入另一个层,其中包含映射到 DTO 的真正“域对象”,从名字上看,它们是“持久性对象”。

Sounds like you may want to re-think having a DTO that directly corresponds to each table in the database.

Rather, a DTO should correspond to something logical in the real-world model that's used behind the Web site. So, for instance, a Customer object might have a collection of Order IDs within it, even though these would be logically stored in two tables in the database.

There is nothing wrong (in fact it's often essential) to have DTO referencing other DTOs, so for instance you could have a Customer class that points to a list of Address classes.

If things get more complex you will most likely want to consider introducing another layer at this point with true "domain objects" that map to your DTOs, which from the sound of it are "persistence objects".

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文