第九章 在N层结构的应用程序中使用EF
不是所有的应用都能完全地写入到一个单个的过程中(就是驻留在一个单一的物理层中)，实际上，在当今不断发展的网络世界，大量的应用程序的结构包含经典的表现层，应用程，和数据层，并且它们可能分布在多台计算机上，被分布到一台单独的计算机上的应用程序的某个领域的逻辑层，并不过多地涉及代理服务器编码，序列化，和网络协议，应用程序可以跨越很多设备，从小到一个移动设备到大到一个包含企业所有账户信息的数据服务器。
幸运的是,EF可应用于WCF，WEB Api等诸如此类的多层框架中。
在本章，我们将尽量涵盖EF中多层应用中的使用，N层是指应用程序的表示层，业务逻辑层，和数据层等被分别布暑在不同的服务器上。这种物理上独立分布有助于可扩展性，可维护性，及程序的后期延伸性，但当一个处理需要跨计算机的时候，会带来性能上的影响。N层架构给EF的状态跟踪带来额外的挑战。首先，EF的ContextObject获取数据发送给客户端后被销毁，而在客户端上的数据修改没有被跟踪。
在更新前，必须根据递交的数据新建一个Context Object，很明显，这个新的对象不知道前一个对象的存在，包括实体的原始值。在本章，我们将看到处理这种跟踪挑战上的工具方法。
在EF的之前版本中，一个开发者能利用“跟踪实体”模板，能帮助我们跟踪被被分离的实体。然后在EF6中，它已经被弃用，但是遗留的ObjectContext将支持跟踪实体，本章将关注基本的用于N层的创建，读取，更新和删除操作。此外，将深入探讨实体和代理的序列化，并发，和实体跟踪的工作方式。
9-1．用Web Api更新单独分离的实体
问题
你想利用基于Rest的Web服务来插入，删除，更新到数据存储层。此外，你想通过EF6的Code First方式来实现对数据访问的管理。在此例中，我们效仿一个N层的场景，控制台应用的客户端调用暴露基于REST服务的Web Api应用。每层使用单独的VS解决方案，这样更有利于效仿N层的配置和调试。
解决方案
假设有一个如9-1图所示的模型
图 9-1. 一个订单模型
我们的模型表示订单。我们想要把模型和数据库代码放到一个Web Api服务后面，以便任何客户都可以通过HTTP来插入，更新和删除订单数据。为了创建这个服务，执行以下操作:
1.新建一个 ASP.NET MVC 4 Web 应用项目，命名为“Recipe1.Service”，并在向导中选择Web API模板。。
2. 向项目中添加一个新的“控制器”，命名为“OrderController”.
3. 添加Order类，代码如Listing 9-1所示：
Listing 9-1. Order Entity Class
public class Order { public int OrderId { get; set; } public string Product { get; set; } public int Quantity { get; set; } public string Status { get; set; } public byte[] TimeStamp { get; set; } }