POCO实体在2层WPF应用程序中 [英] POCO entities in a 2-tier WPF application

问题描述

我需要检索一个实体大图，在UI中进行操作（添加，更新，删除），然后将其全部保存回数据库。在各种SO问题和实验之后，我发现这个大量的分离图更新方法是非常有问题的，所以我现在正在重新思考我的方法。

只是一个2层的WPF应用程序，所以我现在正在考虑在用于操纵实体图形的UI持续时间内存在长时间运行的上下文，这样可以自动跟踪更改。然而，我不知道如何在架构上接近。

该应用程序目前有三个项目 - UI，业务层，以及一个用于edmx&生成实体。我的业务层有一个 CustomerManager 类，公开了一种方法来检索客户图（订单，订单行等），以及一种持久化客户图表的方法。假设UI保持在 CustomerManager 类的相同实例上，因此相同的上下文将跟踪图形的更改（添加和更改实体）。 p>

删除一个实体有点麻烦，因为上下文必须用于这样做，即： -

  context.Set<排序>（）删除（orderToDelete）。 
  

真正寻找一些建筑建议。在我的 CustomerManager 类中，我是否公开一个 DeleteOrder 方法？鉴于我有十几个其他实体类型，我可能需要公开类似的方法来删除订单，产品等。

这是UI的一个明智的做法持有相同的 CustomerManager 实例，还是有更好的方法来管理长时间运行的上下文？ DeleteOrder 方法的合理位置将在我的Customer实体（partial）类中，但是这些类与业务层（这是上下文居住），我想我不能这样做（除非我将上下文传递给DeleteOrder方法）？

解决方案

只有当您的上下文存在于UI中并且UI直接与数据库直接对话以获取和持久存储数据时，生活环境概念才会起作用在您的UI和上下文之间涉及WCF总是导致序列化，并导致实体分离=不跟踪更改（除非您使用STE）。在WCF服务中有长期的生活环境是太有问题的，一般不好的做法。

您是否考虑过WCF数据服务？他们通过使用特殊的客户端上下文来提供客户端跟踪。

I need to retrieve a large graph of entities, manipulate it in the UI (adds, updates, deletes), then persist it all back to the database. After various SO questions and experiments, I'm finding this mass "detached graph update" approach to be very problematic, so I'm now rethinking my approach.

It's only a 2-tier WPF app, so I'm now thinking of having a long-running context that exists for the duration of the UI used to manipulate the entity graph - that way it can track changes automatically. However I'm not sure how to approach this architecturally.

The application currently has three projects - the UI, business tier, and one for the edmx & generated entities. My business tier has a CustomerManager class that exposes a method to retrieve a Customer graph (orders, order lines, etc.), and a method to persist the Customer graph. Assuming that the UI holds on to the same instance of the CustomerManager class, and therefore the same context, changes to the graph (adding and changing entities) will be tracked.

Deleting an entity is a bit more tricky, as the context must be used to do this, i.e.:-

context.Set<Order>().Remove(orderToDelete);

Looking for some architectural advice really. Do I just expose a DeleteOrder method in my CustomerManager class that does this? Given that I have a dozen other entity types, I would presumably need to expose similar methods to delete orders, products, etc.

Is it a sensible approach for the UI to hold on to the same CustomerManager instance, or is there a better way to manage a long-running context? A logical place for the DeleteOrder method would be in my Customer entity (partial) class, but as these classes are in a separate project from the business tier (which is where the context resides), I guess I can't do this (unless I pass the context to the DeleteOrder method)?

解决方案

Your long living context idea will work only if your context lives in UI and UI talks to database directly to get and persist data. Involving WCF between your UI and context always result in serialization and it causes entity detaching = not tracking changes (unless you use STEs). Having long living context in WCF service is too problematic and in general bad practice.

Have you considered WCF Data Services? They provide client side tracking to some extend by using special client side context.

这篇关于POCO实体在2层WPF应用程序中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！