直接从数据库查询构建的业务对象
……叫什么名字？
更详细：对于我的应用程序，我创建了一个很好的业务模型来作为内存中的对象使用。它与存储和视图无关。现在，对于存储层，有一个数据库：我将构建 SQL 查询（越少越好），从相关表中选择/连接等我需要的所有数据。一种“中间层”获取查询结果并构建具有所有关系的业务对象。
问题：您如何称呼这种方法？最佳实践是什么？
这发生在 .NET C# 项目中，但这与此设计问题无关。
（我发现问题 441532 非常相似，但我对更多设计输入感兴趣）
注意：我不采用依赖于自动执行此操作的工具的 ORM 方法，因为应用程序仅需要选定的数据来自一个相对较大的数据库。
...What is it called?
More elaborate: For my application I created a nice business model to work with as in-memory objects. It's storage and view agnostic. Now, for the storage layer, there's a database: I'll construct SQL queries (the fewer the better) that selects/joins etc. all data I need from the relevant tables. A kind of "middle layer" takes the query(s) result and constructs business objects with all relations.
Questions: What do you call this approach? What are the best practices?
This takes place in a .NET C# project but that's not relevant to this design question.
(I found question 441532 to be very similar but I'm interested in more design input)
Note: I do not take the ORM approach that relies on tools that do this automatically because the application requires only selected data from a relatively large database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为这就是所谓的 ORM，或者对象关系映射。
NHibernate 就是这样的一个例子。
I think it's called ORM, or object-relational mapping.
NHibernate is one example of just such a thing.
它通常被称为 DDD——领域驱动设计。
https://stackoverflow.com/questions/tagged/ddd
https://stackoverflow.com/questions/tagged/domain-driven-design
It's generally called DDD - Domain Driven Design.
https://stackoverflow.com/questions/tagged/ddd
https://stackoverflow.com/questions/tagged/domain-driven-design
有不同的 ORM 工具。 Linq to SQL 做了 1:1，这不是你想要的。
您所说的内容与领域驱动设计重叠，您的设计由域，而不是数据库。
在这种情况下，如果您使用的是关系数据库，您仍然需要 ORM，像 Entity Framework 和 NHibernate 这样的 ORM 允许您以任何您想要的方式灵活地将实体“映射”到数据库，如果您的数据库无论出于何种原因需要更改，或者您的实体必须更改，无论出于何种原因，您需要更改的只是中间的“映射”层。
看看 Fluent nhibernate
There are different ORM tools. Linq to SQL do a 1:1, which is not what you want.
What you're talking about overlaps with Domain Driven Design, where your design is driven by the domain, not the Database.
In this case, if you are using a relational Database you still need an ORM, and ORMs like Entity Framework and NHibernate allow you to flexibly "map" your entities to your database in any way you want, in a way that, if your Database needs to change for whatever reason, or you Entities have to change, for whatever reason, all you need to change is the middle "mapping" layer.
take a look at fluent nhibernate