跨层处理对象图的最佳方法是什么？
我们有一个典型的多层/层架构。应用程序 + WCF 服务 + 存储库/EF4/数据库。
我们使用 EF POCO T4 模板的自定义版本来生成我们的实体，并在各个层/层中使用。我们决定不使用 DTO，因为涉及额外的时间/工作。
一个示例对象是森林，它可以具有树木的导航属性，而树木可以具有树叶的导航属性。
添加叶子和处理对象图的最佳方法是什么？数据是从客户端导入的，因此我们不一定知道父森林/树是否已存在于数据库中。
查询服务并检索任何现有的相关对象。附加相关对象的图表或创建新对象并在客户端附加图表。 示例： public Forest GetForest（字符串forestid） 然后 --- public void AddLeaf(Leaf leaf)
在客户端创建森林、树和叶子对象并附加图形。发送叶对象，然后在服务器端执行逻辑以将对象与数据库中的现有对象进行比较。如果需要，条带图、添加不存在的项目和/或附加到现有对象。 示例： public void AddLeaf(Leaf leaf)
在客户端创建森林、树和叶子对象，但不附加图形。发送对象，然后在服务端执行逻辑以将对象与数据库中的现有对象进行比较。添加不存在的项目和/或附加到现有对象。 示例： public void AddLeaf(Leaf leaf, Tree tree, Forestforest)
问题归结为应该在哪里进行逻辑来附加这些相关对象的图形。 附带说明一下，在处理序列化和反序列化的图形时，我有点担心导航属性的“修复”逻辑。看起来这可能会成为一项昂贵的操作。
注意：客户端应用程序是一个正在导入数据的 Windows 服务...因此它不一定是轻量级客户端。 （我们不一定害怕为其添加逻辑。）
We have a typical multi-tier/layer architecture. Application + WCF Service + Repository/EF4/Database.
We are using a customized version of the EF POCO T4 template to generate our entities, that we use across the tiers/layers. We have decided not to use DTO, because of the additional time/work involved.
An example object would be a forest which could have navigation properties of trees which could have navigation properties of leaves.
What is the best approach to add leaves and deal with the object graph? The data is being imported from the client side, so we don't necessarily know if the parent forest/tree already exists in the database.
Query service and retrieve any existing related objects. Attach graph for related objects or create new objects and attach graph on the client side.
example: public Forest GetForest(string forestid)
then --- public void AddLeaf(Leaf leaf)Create the forest, tree, and leaf objects on the client side and attach the graphs. Send the leaf object across and then on the server side perform logic to compare objects to existing objects in the database. Strip graphs if required, add items that do not exist and/or attach to existing objects.
example: public void AddLeaf(Leaf leaf)Create the forest, tree and leaf objects on the client side, but don't attach the graphs. Send the objects across and then on the service side perform the logic to compare objects to existing objects in the database. Add items that do not exist and/or attach to existing objects.
example: public void AddLeaf(Leaf leaf, Tree tree, Forest forest)
The question boils down to where should the logic take place to attach the graphs of these related objects.
On a side note I am a little concerned about the "fixup" logic for the navigation properties when dealing with graphs being serialized and deserialized. It seems like that could become an expensive opearation.
Note: The client application is a windows service that is importing data...so it is not necessarily a light weight client. (We are not necessarily afraid of adding logic to it.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
几个月前我有类似的问题。在玩了很多这个问题之后，我的最终决定是使用你的第三个解决方案（我的客户端始终是网络应用程序）。该解决方案需要编写大量代码，并且包括一些额外的数据库查询，因为每次您想要更新对象时，您都必须首先加载整个对象图。这样做的原因是，在处理分离的对象时，您必须处理 手动更改跟踪。
当您使用第三种解决方案时，您还可以涉及 DTO 并仅在客户端和服务器之间传输真正需要的数据。
如果是有状态客户端（用 .NET 或 Silverlight 编写的 Windows 应用程序），您还可以使用自我跟踪实体和第一种方法。自跟踪实体是变更集模式的实现。他们可以在与上下文分离后跟踪所有更改，但您必须首先从数据库加载实体。在网络情况下，自我跟踪实体不是一个好的选择非 .NET 客户端使用的应用程序客户端或服务。
I had similar question few months ago. After playing a lot with this problem my final decission is to use your third solution (my client is always web application). This solution requires writting a lot of code and it includes some additional database queries because each time you want to update your objects you have to load whole object graph first. Reason for this is that when working with detached objects you have to deal with change tracking manually.
When you use third solution you can also involve DTO and transfers only really needed data between client and server.
In case of statefull client (windows app written in .NET or maybe Silverlight) you can also use self tracking entities and your first approach. Self tracking entities are implementation of Changeset pattern. They can track all changes after detaching from context but you have to load your entities first from DB. Self tracking entities are not a good choice in case of web application client or service consumed by non .NET client.