Web开发技术

Managing Entity Framework ObjectContext lifespan and scope in n-layered ASP.NET applications

2009-06-01T10:50:24Z

Introduction

Since the introduction of the ADO.NET Entity Framework, I've been looking for ways on how to incorporate this new technology in a typical n- layered ASP.NET application. I've started off by replacing the traditional - mostly handwritten - Data Access classes (DAL) with a database generated Entity Data Model (EDM). This offers some great benefits, for example by speeding up development time, and reducing the number of bugs in the DAL.

The middle layer – or Business Logic Layer (BLL) as I like to call it - classes remain effectively the same as in the .NET 2.0 days. The only difference is in how they use the Data Access objects, which needless to say reside in the Data Access Layer (DAL). Instead of referencing their counterpart DAL classes (for example the ProductBLL class methods may call data access methods in the ProductDAL class), the BLL classes now use an instance of an ObjectContext for their data access purposes. In this role, the ObjectContext class replaces the more traditional DAL classes.

Up till now everything I've described has been pretty straightforward. However, some problems may arise when you start to think about how to use an ObjectContext in a scenario where you have multiple BLL classes, and you want to be able to exchange business objects (i.e. domain entities) between instances of those classes. Since all changes are tracked by an ObjectContext (instead of by the objects themselves), it's not always easy to "mix" objects that originate from different ObjectContext instances. However, there are several ways to share ObjectContext instances between BLL classes within the BLL. Each with its own advantages and disadvantages.

One way to do it for example, is to use a single ObjectContext for each business transaction (in a Unit of Work pattern). Another way to do it, is by globally sharing a single ObjectContext instance between all BLL classes. Each of these methods will be discussed in more detail later in this article.

The problems of working with multiple ObjectContext instances

Like I mentioned in the introduction, working with multiple instances of an ObjectContext class simultaneously can be a bit troublesome. In the Entity Framework changes are tracked by an ObjectContext instance, instead of by the business objects/entities themselves. To be able to define and save a relationship between objects that originated from different ObjectContext instances, you would first have to “detach” an entity (i.e. business object) from its originating ObjectContext instance, and then “attach” it to the ObjectContext of the other entity. For example:

NorthwindObjectContext objectContext1 = new NorthwindObjectContext();

Categories category = objectContext1.Categories

.FirstOrDefault(c => c.CategoryID == 1);

NorthwindObjectContext objectContext2 = new NorthwindObjectContext();

Products product = objectContext2.Products

.FirstOrDefault(p => p.ProductID == 1);

/* Detach from originating ObjectContext: */

objectContext1.Detach(category);

/* Attach to the other ObjectContext: */

objectContext2.Attach(category);

/* Define a relationship between the category and product objects: */

product.Categories = category;

objectContext2.SaveChanges();

Moreover, the Detach() method only detaches the object that was supplied as an argument. It does not automatically detach related objects.

The code sample above is just a demonstration of the concept of “detaching” and “attaching” entities. Obviously, I could have just loaded both the category and product objects from the same ObjectContext instance, and thus avoiding any problems whatsoever. This is also true for projects that query an Entity Data Model (EDM) directly in their Presentation Layer (in for example the code behind files). However, in my projects – no matter how small – I always use a middle layer (BLL) to store my LINQ-to-Entities queries and business logic. It’s my preferred way of working, because it promotes maintainability and extensibility. It also allows me to unit test my code.

Working with a middle layer (BLL) also means that you will be dealing with multiple BLL classes. There will probably be a separate BLL class for each of your business objects (i.e. domain entities). For example if we look at our code sample above, we might have created a ProductsBLL and a CategoriesBLL class. Business objects returned from instances of those classes, may define relationships with one another. Persisting these relationships will result in an exception being raised if both of the BLL classes use different ObjectContext instances. So we have to either make sure that both of the BLL classes use the same ObjectContext instance, or that we have “manually” tied the objects who defined the relationship to the same ObjectContext instance.

Writing code for attaching and detaching entities in a n-layered ASP.NET application can sometimes become a bit cumbersome, and moreover it’s often unnecessary. There are several good ways of sharing your ObjectContext instances among your BLL classes. In the sections that follow, I will discuss a few of these ways in detail. In the sample code that I have provided, I’ve also included a small generic framework for managing ObjectContext instantiation in your middle layer classes.

One shared static ObjectContext

Lets first start off with a way of sharing an ObjectContext that isn’t suitable for ASP.NET webapplications. I’ve read a lot of forum posts on the internet, in which developers tend to use an ObjectContext as a static class member. In this way the ObjectContext can be globally shared between all classes that use it. It offers some great flexibility, since all business objects/entities in the application originate from the same ObjectContext instance.

Listing 1: Using a static ObjectContext

1. private static NorthwindObjectContext _objectContext;

2. /// <summary>

3. /// Returns a shared static NorthwindObjectContext instance.

4. /// </summary>

5. public NorthwindObjectContext ObjectContext

6. {

7. get

8. {

9. if (_objectContext == null)

10. _objectContext = new NorthwindObjectContext();

11. return _objectContext;

12. }

13. } .

However, you shouldn’t use a static ObjectContext in an ASP.NET application, since static members have a lifespan beyond that of a single HTTP request. They’re actually bound to the lifespan of the AppDomain, which might be minutes or hours. In fact, static class members in ASP.NET are even shared between multiple threads and users of the application. Using the same ObjectContext instance from within multiple threads simultaneously can cause serious problems.

It’s also generally accepted that ObjectContext instances should have a short lifespan, so keeping an ObjectContext around for minutes or even hours is probably not a good practice. But if you’re looking for the flexibility that is provided using a static ObjectContext, then have a look at the solution that is presented in the next section.

One shared ObjectContext instance per HTTP request

Since sharing an ObjectContext as a static member in an ASP.NET application is a no-go, we have to find some other way to achieve similar flexibility. To do this we have to somehow store an ObjectContext instance in a central place for the lifespan of one - and only one - HTTP request. This is where the HttpContext.Current object comes into place.

The Items property of the HttpContext.Current object is a Hashtable for storing objects on a per-request basis. All of your BLL (middle layer) classes have access to this property, so this is a place in which we can store an ObjectContext instance, and then share it between all instances of those classes.

Listing 2: Using the HttpContext.Current.Items property

1. /// <summary>

2. /// Returns a shared ObjectContext instance.

3. /// </summary>

4. public NorthwindObjectContext ObjectContext

5. {

6. get

7. {

8. string ocKey = "ocm_" + HttpContext.Current.GetHashCode().ToString("x");

9. if (!HttpContext.Current.Items.Contains(ocKey))

10. HttpContext.Current.Items.Add(ocKey, new NorthwindObjectContext());

11. return HttpContext.Current.Items[ocKey] as NorthwindObjectContext;

12. }

13. }

It’s a good practice to use a “Lazy Load” pattern in this scenario, so that we only create a new ObjectContext instance when we actually need one.

By globally sharing an ObjectContext instance between classes on a per-request basis, you’ll make sure that every business object in your ASP.NET webapplication originates from the same ObjectContext instance. In this way, you won’t have to worry about which object is being tracked by which ObjectContext, and you can easily exchange business objects (i.e. entities) between all of your BLL classes. Since the ObjectContext instance has the lifespan of only one HTTP request, it’s also relatively short lived.

Note:

Be wary of any asynchronous operations that may occur within your ASP.NET application, when using a globally shared ObjectContext instance. Two or more threads simultaneously trying to update data using the same ObjectContext instance can cause serious problems.

One ObjectContext instance per business transaction

This is the last method of managing an ObjectContext lifespan that I’ll be discussing in this article. Using this method we will be creating and using one instance of an ObjectContext class within the scope of a business transaction. After the business transaction is complete, we will save all changes to the underlying data store and then dispose the ObjectContext instance.

By a business transaction I mean a series of operations that atomically belong together. For example: in a webshop application, if we want to store an order in our system, we would first have to create an Order object. Next we would convert the contents of the shopping cart into Orderline objects. These Orderline objects would then have to be added to the Order object. Only after these steps are complete, we can safely store the complete Order object to the database. By using the Entity Framework in such business transactions, changes should be tracked by one single instance of an ObjectContext class. Doing so we are actually applying the “Unit of Work” pattern.

Sharing an ObjectContext within the scope of a business transaction is a trivial task in an ASP.NET application that doesn’t make use of BLL classes. However, in applications that do have a middle layer things become a little bit harder. We need to somehow “connect” the BLL instances within the scope, so they can all use the same ObjectContext instance. This is best done using some sort of helper object, which would contain the ObjectContext instance, and thus defining the scope. We could then for example create an “AddToScope” method on the helper object, which would be responsible for placing the BLL instances into scope. However, there is a more elegant and transparent construction possible. By mimicking part of the behavior of the .NET Framework’s TransactionScope class, we could make our BLL classes self-aware of the scope they currently belong to.

In the sample code below, an instance of the custom UnitOfWorkScope class in conjunction with a (C#) “using” statement is responsible for defining the ObjectContext scope. All BLL instances created within scope can automatically detect it, and therefore use the same ObjectContext instance.

Listing 3: Defining the scope of a business transaction

1. /* Create a new ObjectContext scope, in which all BLL (middle layer) objects share

2. * the same ObjectContext instance: */

3. using (new UnitOfWorkScope(true)) /* "true" flag indicates that all changes

4. * should be saved at the end of the scope. */

5. {

6. /* The OrderBLL class can automatically detect the current scope: */

7. OrderBLL orderBLL = new OrderBLL();

8. /* The OrderlineBLL class can automatically detect the current scope: */

9. OrderlineBLL orderlineBLL = new OrderlineBLL();

10. /* The ProductBLL class can automatically detect the current scope: */

11. ProductBLL productBLL = new ProductBLL();

12. /* Create a new order: */

13. Order newOrder = new Order();

14. newOrder.FirstName = "Jordan";

15. newOrder.LastName = "van Gogh";

16. // .. add more order properties here ...

17. /* Make sure the newOrder object will be added to the data store: */

18. orderBLL.Add(newOrder);

19. /* Convert the ShoppingCartItem objects into Orderline objects: */

20. foreach (ShoppingCartItem cartItem in _shoppingCart.Items)

21. {

22. Orderline newLine = new Orderline();

23. /* Retrieve a Product object based on its PK: */

24. Product product = productBLL.GetProductByID( cartItem.ProductID );

25. /* We should be able to define a relationship between the

26. * newLine object and the product object since we are currently

27. * in a "Unit of Work" scope, in which both orderlineBLL and

28. * productBLL objects share the same ObjectContext instance: */

29. newLine.Product = product;

30. newLine.Quantity = cartItem.Quantity;

31. /* Make sure the orderline object will be added to the data store: */

32. orderlineBLL.Add(newLine);

33. /* Define a relationship between the newLine and the newOrder objects: */

34. newOrder.Orderlines.Add(newLine);

35. }

36. } /* End of scope. The newOrder object and it's Orderline objects will

37. * now be persisted to the underlying data store. */

After studying the code sample above, those who aren’t familiar with the TransactionScope class may be wondering how the BLL objects can automatically detect the current scope, just by placing them in a “using” construct. Well, this is actually achieved by using a thread static class member. Values of thread static class members are only bound to the current thread, instead of the entire application as is the case with normal static members. Besides their scope, they act in the same way as normal static members. In .NET we can make a static class member thread static by adding a [ThreadStatic] attribute to it.

The UnitOfWorkScope class encapsulates an ObjectContext instance. By setting the value of a thread static member to a UnitOfWorkScope instance, we have a way of sharing its encapsulated ObjectContext among our BLL objects within the current thread. It’s almost similar to sharing and using a global static ObjectContext, except this time it’s only being shared within the current thread.

Listing 4: The UnitOfWorkScope class implementation

1. /// <summary>

2. /// Defines a scope wherein only one ObjectContext instance is created,

3. /// and shared by all of those who use it. Instances of this class are

4. /// supposed to be used in a using() statement.

5. /// </summary>

6. public sealed class UnitOfWorkScope : IDisposable

7. {

8. [ThreadStatic]

9. private static UnitOfWorkScope _currentScope;

10. private NorthwindObjectContext _objectContext;

11. private bool _isDisposed, _saveAllChangesAtEndOfScope;

12. /// <summary>

13. /// Gets or sets a boolean value that indicates whether to automatically save

14. /// all object changes at end of the scope.

15. /// </summary>

16. public bool SaveAllChangesAtEndOfScope

17. {

18. get { return _saveAllChangesAtEndOfScope; }

19. set { _saveAllChangesAtEndOfScope = value; }

20. }

21. /// <summary>

22. /// Returns a reference to the NorthwindObjectContext that is created

23. /// for the current scope. If no scope currently exists, null is returned.

24. /// </summary>

25. internal static NorthwindObjectContext CurrentObjectContext

26. {

27. get { return _currentScope != null ? _currentScope._objectContext : null; }

28. }

29. /// <summary>

30. /// Default constructor. Object changes are not automatically saved

31. /// at the end of the scope.

32. /// </summary>

33. public UnitOfWorkScope()

34. : this(false)

35. { }

36. /// <summary>

37. /// Parameterized constructor.

38. /// </summary>

39. /// <param name="saveAllChangesAtEndOfScope">

40. /// A boolean value that indicates whether to automatically save

41. /// all object changes at end of the scope.

42. /// </param>

43. public UnitOfWorkScope(bool saveAllChangesAtEndOfScope)

44. {

45. if (_currentScope != null && !_currentScope._isDisposed)

46. throw new InvalidOperationException("ObjectContextScope instances " +

47. "cannot be nested.");

48. _saveAllChangesAtEndOfScope = saveAllChangesAtEndOfScope;

49. /* Create a new ObjectContext instance: */

50. _objectContext = new NorthwindObjectContext();

51. _isDisposed = false;

52. Thread.BeginThreadAffinity();

53. /* Set the current scope to this UnitOfWorkScope object: */

54. _currentScope = this;

55. }

56. /// <summary>

57. /// Called on the end of the scope. Disposes the NorthwindObjectContext.

58. /// </summary>

59. public void Dispose()

60. {

61. if (!_isDisposed)

62. {

63. /* End of scope, so clear the thread static

64. * _currentScope member: */

65. _currentScope = null;

66. Thread.EndThreadAffinity();

67. if (_saveAllChangesAtEndOfScope)

68. _objectContext.SaveChanges();

69. /* Dispose the scoped ObjectContext instance: */

70. _objectContext.Dispose();

71. _isDisposed = true;

72. }

73. }

74. }

The UnitOfWorkScope class should only be used in a “using” construct. At the start of the construct a new UnitOfWorkScope instance is created. The constructor of this class creates a new ObjectContext instance. This ObjectContext is then shared and used by other BLL objects within the “using” construct. At the end of the construct the Dispose method of the UnitOfWorkScope object is automatically called, which in turn disposes the encapsulated ObjectContext instance.

In our BLL classes we can use the internal static CurrentObjectContext property to get a reference of the ObjectContext instance that’s bound the current scope. We could for example define a ObjectContext property within these classes, as in the code sample below:

Listing 5: Using the CurrentObjectContext property of the UnitOfWorkScope class

1. private NorthwindObjectContext _objectContext;

2. /// <summary>

3. /// Returns the ObjectContext instance that belongs to the

4. /// current UnitOfWorkScope. If currently no UnitOfWorkScope

5. /// exists, a local instance of the NorthwindObjectContext class

6. /// is returned.

7. /// </summary>

8. protected NorthwindObjectContext ObjectContext

9. {

10. get

11. {

12. if (UnitOfWorkScope.CurrentObjectContext != null)

13. return UnitOfWorkScope.CurrentObjectContext;

14. else

15. {

16. if (_objectContext == null)

17. _objectContext = new NorthwindObjectContext();

18. return _objectContext;

19. }

20. }

21. }

Using one “fresh” ObjectContext instance per business transaction, is generally considered to be a good practice. And by using the techniques I demonstrated in this section, you can also make sure that it’s properly disposed when it’s no longer needed.

Note:

Using thread static class members in a wider scope than in the specified “using” construct can result in unpredictable behavior. This is because ASP.NET threads might be re-used, and thus if there are any leftover thread static values, they might also be unknowingly used again.

Sample Application

To demonstrate the techniques that I’ve described in this article I've created a small sample application, based on a part of the Northwind database. It also includes a small ready-to-use generic ObjectContext management framework. As you may see in the screenshot of the VS solution explorer below, I've created a 3-layered ASP.NET application.

Oxite Review

2009-05-31T04:11:34Z

I’m really trying not to be negative with this post. The people behind Oxite are good folks and don’t deserve any hate. They have made a mistake, though. A mistake I think needs to be corrected and requires some immediate action.

My advice, if anyone cares:

Oxite should be pulled immediately until the larger issues (including and especially the major security vulnerabilities) can be addressed satisfactorily.
Oxite should NOT be used as any sort of Best Practice or official guidance by Microsoft. The Oxite folks have been VERY open and clear that this is NOT anything official or supposed to be recommended guidance. Unfortunately, though, many WILL take it as that no matter how many disclaimers they have to click though.
If you are not familiar with ASP.NET MVC or MVC in general, you should avoid Oxite for the time being as there are several anti-patterns that may set you off on the wrong footing in the future.

I would prefer not to go into any specific problems Oxite may have. From my days as a consultant, I know that this will be taken as gospel by many and used off-the-shelf with little modification to build many production web applications. This could be a minor disaster for many companies and other organizations who may be the unwitting victim of its problems. This may seem overly dramatic, but if you have not spent any significant time consulting in the .NET space and aren’t aware of things like PetShop or the various ASP.NET quick start applications then trust me, it could become that bad – and fast.

The folks who are involved with Oxite’s development are open to communication and are engaging the community and are working with everyone to try to balance the needs of everyone. However, until its most major issues (including significant security vulnerabilities) can be addressed, I think it would be best to pull it or lock it down on CodePlex to prevent it being referenced by the community and any more confusion spread.

We all have an opportunity to improve the .NET space here and I think we should take this opportunity. ASP.NET MVC will soon be released, and I’d hate for the first major impression of its usage from Microsoft be problematic.

Finally, I appreciate the efforts of the Oxite-involed folks and the sincere attempt at openness and contribution. This is a significant contribution and we are very thankful for this. As much as many members may be upset about Oxite, underneath, I think everyone is appreciative (though we/they may have a bad way of showing it) that this even happened in the first place. This is definitely a step in the right direction. The next step, I think, is to crank up the quality a little more so we can all have our cake and eat it, too!

Several folks, including Microsoft employees and members of the Oxite team, have politely requested I do a post or few on the problems I see with Oxite and why I previously recommended that it is not a good example/sample from which to base future products.

At first, I was reluctant to do this since I was afraid people might see it as some sort of attack or other negative. But since I have been encouraged by several folks as mentioned, I feel that this will be constructive and received as a “good thing”.

Setup

First, I want to make sure that everyone knows there’s no attack here, nothing personal, this is purely about code and in no way a reflection on the individual. The way we roll at Dovetail is that we are dispassionate about our code and follow practices such as collective code ownership, refactoring mercilessly, pair programming, and no premature optimization, which help disassociate our passion, creativity, and soul from the code so that we can objectively look at parts and say “that is bad” or “this is good” and mean it. So I’m coming from a viewpoint that the code is code and should be mercilessly, objectively torn apart and made to stand on its own merits, independent of who wrote it and under what conditions. I say that code can be objectively determined to be “good” or “bad” and patterns and anti-patterns identified with certainty and no subjectivity.

Second, please consider Nate Kohari’s recent great post on debate vs. argument; ego, pride, personal attachment, etc. as this also helps to frame where I’m coming from. During this review, I’m not going to mention people, their motivations, their goals and desires, etc. I’m only going to talk about the code and the requirements of the features the code is trying to accomplish.

With these things in mind, let us now objectively view Oxite as a body of work, independent of any individuals involved in its creation, that must stand alone and be evaluated solely on its own merits.

As a Sample Application…

Oxite is a “real world sample” and not necessarily official guidance (a la the Patterns & Practices type stuff). As a sample, the packaging of Oxite is good as it includes many facets of a project from the domain, to the database, to the front end, etc. Perhaps it could’ve included some more documentation (maybe I missed it? I didn’t look very hard, admittedly). Since this wasn’t positioned as a guidance project, people should avoid referring other people to it as any sort of best practice or official anything from Microsoft. As ASP.NET MVC matures after release, I expect we’ll start seeing more official guidance from P&P and other groups within Microsoft.

Recommendation: [For MS, primarily, as this problem is mostly unique due to MS’ position with respect to .NET] Perhaps MS could establish more official terms to set expectations for customers. “Sample” is not “Guidance” is not “Recommendation” is not “Stance”, etc.

As an OSS project…

Oxite is an open-source project. It is released under the Microsoft Public (Ms-PL) license which is quite permissive and in line with generally accepted good practices for open source. This is very good. Oxite is hosted on the CodePlex project site and (correct me if I’m wrong) is not accepting patches from the public due to, I believe, concerns of patent/IP violations and such. This is not very good. Part of being open is allowing people to modify it without having to fork the code. At the very least, we can fork it which is certainly heads above what we normally get from large corporations which is either no visibility, or only push releases. Overall, I’m very pleased MS has taken this approach with Oxite and I’d like to greatly encourage them to pursue this method of release in the future. My only critique is that maybe they find a way to accept patches from the public (I’m ok if they need to fill out some affidavit or other legal form).

As a .NET OSS project, I was particularly disappointed in the fact that the high-level Visual Studio Team *.* SKU’s were used in its creation. I don’t have the numbers, but I’m willing to bet that the vast majority of .NET developers do not have the full Visual Studio suite (Database, Test, etc) and so they won’t even be able to open the SLN file without having to hack CSPROJ files and such (like I had to). There is a SLN file for Visual Web Developer Express that will help get people going, but this seems like an afterthought, rather than a good strategy.

Also missing is any sort of automated build script. What if I want to set up Oxite in my own CI server to pull down the trunk nightly and do builds in my environment? This is pretty standard among .NET OSS projects, so I was disappointed that this was missing.

Recommendation: [For MS and other companies seeking to release .NET OSS] Either let these things go out to be full OSS projects and release the copyright and liability to the public somehow to achieve full indemnity from possible patent or copyright infringement. And/or, find a legal framework for being able to accept patches from individuals in the community.

Recommendation: [For anyone managing an OSS project] Please take a little more care to ensure that you have respected generally accepted minimum expectations of an OSS project such as an automated build and decent test coverage.

Tests!?!

Technically, this should just go under the previous section, but it’s significant enough that it should be called out on its own. Unless I’m missing something, there are around 51 tests for the entire project and those tests cover only the MetaWeblog API handling and the XmlRpc handling. Without having run a coverage tool, I’m guessing that coverage is below 10%. I’m very serious when I say that this would be considered unacceptable on most projects I’m involved with. I would be put on probation or possibly removed from a project at a corporate customer or removed as a committer on an OSS project for committing code with <10% coverage. Quite frankly, it is dangerous to have a large application with <10% test coverage. It is also a liability in that future changes become ever increasingly difficult with the friction and fear of change due to the unknown of how changes may break functionality and cause regression bugs.

The tests that are there (for example, I count 49 in the MetaWeblogServiceTests) are a little heavy. In my opinion, this indicates that MetWeblogService has too many responsibilities and is putting too much burden on the tests to account for the excessive dependencies of MetaWeblogService. It’s also curious that no mocking framework was used, but instead (excessive, IMHO) use of fake, concrete test implementations were used. Several(though not most) of the tests are asserting too many things which leads to brittle tests and can cause friction during refactoring.

Testing is not just about ensuring the current code works properly (that is important), but also explaining how the code works so that, in the future, when changes are made, maintenance programmers understand why the change they made broke other things. This enhances change confidence and encourages fearless refactoring which is key to maintaining a rapid, sustainable pace throughout the life of the development.

But I digress, this subject is perhaps too large and requires a post in an of itself. Suffices to say that there are too few tests and the tests that are there, while meaningful, will contribute to increased friction over the life of the product and should probably be refactored as the project goes on.

Recommendation: [For anyone managing an OSS project] Tests serve many purposes including encouraging contributors because they can see how things are supposed to work, and can be more confident in their changes, knowing that tests will most likely catch them if they make a big mistake. At this point, going BACK and adding tests would likely be a waste of time. Going forward, all new features should be developed with tests (preferably test-driven as this helps keep your design on track, it’s a curious side effect of writing client code FIRST, then the code to make it work). Any bugs that pop up between now and then should first have a test that reproduces the problem, then the fix should be implemented, and the tests should then pass (without modification). If they don’t pass, the fix isn’t quite right. If, during the fixing of bugs, you discover other problems or realize there’s more refactoring to do, do that code test-driven along with the bugfix. Try to keep changes minimal and focused, though, and with a high degree of coverage (preferably >90%, but that’s not a hard rule).

Test should be small, easy to write, and not require a lot of setup. If they’re not meeting ALL of these three criteria, you have a design problem and need to reinvestigate. It happens all the time that I find myself violating one or more of these rules, and the tests help to point me to where in my design I screwed up. This is a natural thing and shouldn’t be seen as negative. You caught the problem early and tests helped spot it and point you in the right direction. Just keep these criteria in mind as you proceed.

Domain

The heart of any good project is its domain. The domain is the understanding and model of the core problem this application is trying to solve. The domain is king. It should be fat, juicy, and contain the core logic that constitutes how this application behaves. Everything else in the application serves the domain by either bringing information to it, or relaying information out of it to the customer (users, other applications, data storage, etc). Great care and investment should be placed on the domain of the application as it is your greatest and most important asset. Principles, patterns, and practices have evolved around this very integral part of application design. Entire books have been written. These include Domain Driven Design (Evans) and Applying Domain-Driven Design and Patterns: Using .NET (Nilsson), among many others.

An important part of key domain object model design is to do it independent of persistence concerns (known as “Persistence Ignorance”). Object Oriented Design is a fundamentally different problem than Relational Data Model Design and each should be done independent of the other to avoid the patterns of one being misapplied in the other. The intermediary between the contrary physics of these two worlds is the Object/Relational Mapper (ORM) such as NHibernate, LLBLGen Pro, and, to a lesser extent, ADO.NET Entity Framework and the now defunct Linq2SQL.

In Oxite, the domain appears to have been driven from the relational model (i.e. database) which has caused some interesting problems that had to be worked around and have hampered the domain (we’ll get to this later). The data provider used was Linq2SQL. Object/database design were achieved using the Linq2SQL designer-generated classes. These classes are partial classes which allow the application to create the other half of the partial class in another file. In these partial classes are added the property-changed, relationship, and other data-concerned handling/functionality. Also, each partial adds an interface (i.e. IPost for the oxite_Post object) presumably to hide away some of the details of Linq2SQL.

Recommendation: Domain objects should be POCO objects with no attachments to or knowledge of the database whatsoever. You can have class hierarchies (but proceed cautiously and light here) and entities can have interfaces, but this should be a rare occurrence and should not required of all of them. The objects should be able to be used and their functionality fully useful without requiring any backend infrastructure, services, database, etc. When it comes to persistence, the persistence framework should “just work” and support the objects naturally without them having to implement any special interfaces or have to do anything special (i.e. including support for transparent lazy loaded collections, and none of this EntitySet business). If your ORM can’t do that, consider one of the already available, major, post 1.x version offerings that have been proving themselves for years on the market in battle.

Linq2SQL Problems

You may have noticed earlier when I said “to a lesser extent” when talking about Linq2SQL as an ORM. This is because Linq2SQL is missing a lot of key functionality to be considered as a full-fledged ORM. Among these are automatic change-tracking and cascade support, transparent lazy loading, and database data-type minutiae handling. These things are just a given in a more mature and full-featured ORM like NHibernate, for example.

I also said that the use of Linq2SQL has caused some interesting problems. Aside from having to manually do change tracking, deal with underlying SQL data-types, and having to deal with relationships manually, the Linq2SQL-based objects have the pernicious problem of not being able to be used (easily) without being connected to the database. This is the opposite of “Persistence Ignorance.” To counter this problem, Oxite has entity interfaces (i.e. IPost). Generally speaking, interfaces for entities is a smell. In this case, the smell is definitely pointing to a problem and using interfaces is merely a band-aid for that problem.

Recommendation: Don’t use Linq2SQL as it’s simply too much friction and lacks critical features. Use a full-featured ORM like NHibernate or several of the commercial ones available.

Interface Entities

I mentioned above some of the problems with interface-based entities like IPost, ITag, etc. I wanted to call out a specific example of where something like this can go very wrong. In the partial class declaration of class oxite_Tag, the Parent property has a significant problem for reuse and future maintenance. For reference, see PartialClasses.cs, line 646.

The problem with this property is that it means oxite_Tag is only valid with other oxite_Tag implementations of ITag. This is what’s known as a violation of the Liskov Substituion Principle and/or the Open Closed Principle. Put simply, anyone doing anything with ITag would be surprised if they started getting InvalidCastExceptions because of some problem lurking deep in your design. If the intention is that oxite_Tag can only work with other oxite_Tag’s, then it shouldn’t use an ITag interface when it doesn’t really mean it.

Is this nitpicking? Kinda. The oxite_Tag problem may never get hit, but it is a potential landmine in your code, waiting to explode on an unsuspecting maintenance programmer. If your design has special magic and gotchas, you have a problem.

Recommendation: Interfaces should be intention revealing and their implementation contain no surprises. Interfaces also should only be used where true abstraction is needed. Entities/domain modeling is generally one of these places where abstraction is not necessary (and therefore interfaces shouldn’t be used).

Database Assumptions

The entities in Oxite have several assumptions specifically about SQL Server (heavy use of SqlDateTime.Min/MaxValue). This is yet another problem that stems from the of usage of Linq2SQL. To address this, Oxite has abstracted entities (behind interfaces such as IPost, ITag, etc) and abstracted the repositories behind interfaces (good, actually!) and these repositories are accessed through an “IOxiteDataProvider” implementation, such as OxiteLinqToSqlDataProvider (bad, more on this later). This is not the appropriate place to abstract database concerns. I’ll cover proper layering and proper concern separation later. For now, the relevant point is that concerns about the specific usage of the underlying database have seeped up too high in the layering of the application, necessarily requiring more and more complex architecture and abstractions to work around this. This means implementing an “IOxiteDataProvider” is more difficult for would-be implementers than it should be and much duplication of code will likely result. It also prohibits the use of a fat/rich domain model which leads me to the next section (Anemic Domain).

Recommendation: Keep database-specifics as close to the database as possible and, to the maximum extent possible, completely out of your application code. This is best handled by a persistence framework such as an ORM like NHibernate. Doing this will make it much easier to implement different data access strategies later in the product’s life and to support a wider range of database platforms with little to no change to most of the application code. You’ll still have to test on each database you plan on supporting, but the code should not have to change (much) when adding support for a new database.

Anemic Domain

Another problem with the domain of Oxite is that all the entity objects are anemic with a few minor exceptions. An anemic domain model is one that is largely if not entirely comprised of getters/setters and are just data containers (DTOs for the database, if you will). This necessarily forces all the interesting logic of the domain to be the responsibility of other, perhaps less appropriate, parties which can lead to “service explosion” or “manager anti-pattern”, etc.

Like I said earlier, domains should necessarily be fat and contain all the relevant logic. They should contain concepts such as “required” and “unique”, etc and these concepts should flow out into the rest of the application including into the relational database model. The domain should prevent invalid states/situations and should enforce rules throughout the system. This is not to be confused necessarily with the antiquated concept of a Business Logic Layer, however.

Recommendation: The domain model should be “fat” and rich. It should be modeled according to the current understanding of how the domain SHOULD work (i.e. X is required, there can only be 1 Y per every X, When an A is added to a B, that B’s “A” property should be set to the newly-related A instance, etc, etc, etc).

Conclusion of Part 1

It looks like this will be a multi-parter, because it’s already long and I haven’t even gotten to the majority of issues. By the time this review is done, I’d like to cover the following things by the time I’m done (wish me luck):

Problems with the Provider anti-pattern
Incorrect layering and slicing of abstractions
Lack of Dependency Injection (in some cases) and IoC causes cascading design problems
High Coupling, Low Cohesion
Single Responsibility Principle, Separation of Concerns, and Interface Segregation Principle violations causing problems
What is a “Controller” for?
What is a “View” for?
Mystery Meat, Magic Strings, and Bags of Holding +1
Presentation Models
Logic in Views Is Bad
ASP.NET MVC guts leaking up into all parts of the app
(other stuff that will probably come up in the comments that I didn’t think of)

实体框架中的POCO体验

2009-05-31T03:53:01Z

【译者按】 Entity Framework 1.0 发布也有一段时间了，但感觉用的人很少。其中一个很大的原因，也许就是不支持POCO。要知道，Entity Framework 1.0的做法是让你的实体从EF的基类继承而来，这对很多人，特别是崇尚DDD的人来说，那是一副难以下咽的药啊。曾有微软开发人员提供了一个 POCO Adapter，但那究竟不是正规的做法。Visual Studio 2010 和 .NET 4.0 提供了许许多多的新特性，真是让人激动，向往，大有一种回到.NET 1.0 刚出来时的感觉。春天啊（应该是夏天啊），你终于回来了（虽然早晨/晚上还是unseasonably冷）。其中的Entity Framework 4.0版本将提供POCO支持，对很多人来说，这是开始使用Entity Framework的时候了。ADO.NET 团队博客上贴出了一些关于EF和POCO的贴子，非常值得一读。

【原文地址】POCO in the Entity Framework: Part 1 - The Experience
【原文发表日期】 21 May 09 05:46 PM

上个星期，我在《POCO初览》中提到了POCO实体支持是我们加到Entity Framework 4.0中的新功能之一。这个星期，我要对Entity Framework 4.0中POCO支持的细节进行深入讨论。

要讨论的东西很多，包括

Entity Framework 4.0中总的POCO体验
POCO的变化跟踪
关系修整
复杂类型
延迟（懒式）装载和显式装载
最佳实践

在这个贴子中，我将主要着重于总的体验，这样，你可以马上启用Entity Framework 4.0中的POCO支持。我将使用一个简单的例子做示范，这样，你可以看到在Entity Framework 4.0中使用POCO的感觉。我将使用Northwind数据库，在随后的贴子中，将继续建立在这个例子的基础之上。

第一步： 创建模型，关闭默认的代码生成

虽然POCO允许你以透明持久化的方式编写自己的实体类，但还是有必要“接入”持久性和EF元数据，这样你的POCO实体可以从数据库中复原，以及持久化到数据库中。为实现这个，你还是需要使用实体框架设计器创建一个实体数据模型（Entity Data Model），或者提供跟你在Entity Framework 3.5中生成的完全一样的CSDL, SSDL 和 MSL 元数据文件。所以，首先，我将使用ADO.NET实体数据模型向导（Entity Data Model Wizard）来生成一个EDMX。

创建一个类库项目来定义你的POCO类型，我将其命名为NorthwindModel。这个项目与持久性毫不相关，对实体框架没有依赖性。
创建一个类库项目，它将包含与持久性相关的代码，我将其命名为NorthwindData。这个项目除了对NorthwindModel项目有依赖外，还对实体框架(System.Data.Entity)有依赖。
在NorthwindData 项目中添加新项，加一个名为“Northwind.edmx ”的ADO.NET实体数据模型（这么做将自动在项目中添加对实体框架的依赖）。
选择“从数据库生成”，给Northwind数据库建造模型
暂时只选Categories和Products这两个你感兴趣的表到你的实体数据模型中。

至此，生成了可以为我所用的实体数据模型，但在开始编写代码前，还有最后一步：关闭代码生成。毕竟你感兴趣的是POCO啊，请去除负责从Northwind.edmx生成基于EntityObject代码的Custom Tool（自定义工具）属性，这将关闭你的模型的相应代码生成。

现在，我们可以编写POCO实体了。

第二步： 编写你的POCO实体

我将为Category和Product编写简单的POCO实体，这些类将加到NorthwindModel项目中去。注意，我在这里展示的，不应该看成是最佳实践，这里的意图只是示范可以工作的最简单的例子。在以后我们将根据需要将对这些例子进行扩展和定制，之后建立在其基础之上，使用Repository和Unit of Work模式做进一步的扩展。

这里是Category实体的样例代码：

    public class Category

        public int CategoryID { get; set; }

        public string CategoryName { get; set; }

        public string Description { get; set; }

        public byte[] Picture { get; set; }

        public List<Product> Products { get; set; }

注意，在模型中我既为标量字段定义了属性，也定义了导航属性。模型中的导航属性（Navigation Property）转换成了List<Product>。

类似地，Product实体可以这样编写：

    public class Product

        public int ProductID { get; set; }

        public string ProductName { get; set; }

        public int SupplierID { get; set; }

        public string QuantityPerUnit { get; set; }

        public decimal UnitPrice { get; set; }

        public Int16 UnitsInStock { get; set; }

        public Int16 UnitsOnOrder { get; set; }

        public Int16 ReorderLevel { get; set; }

        public bool Discontinued { get; set; }

        public Category Category { get; set; }

在这个例子中，因为其间的关系，一个Product只允许属于一个Category，因此我们有一个对Category的引用（而不象Category中的导航属性，是一个List<T>集合）。

第三步： 编写你的实体框架上下文

为把所有这些东西结合在一起，我所要做的最后一件事情是，提供一个上下文实现（就象使用默认的代码生成时你得到的ObjectContext实现一样）。上下文（context）是把持久化意识带进你的应用的胶水（glue），它允许你编写查询，将实体复原，以及将变化存回到数据库中去。该上下文将是NorthwindData项目的一部分。

为简单起见，我将我们的上下文类包括在了包含实体类型的同个类库项目中了，但在我们讨论诸如Repository 和Unit of Work等模式时，我们将做这样的设置，即，你将拥有一个纯粹的POCO类库，不带任何一丝与持久性相关的东西。

这里是针对我们场景的简单的上下文实现：

public class NorthwindContext : ObjectContext

        public NorthwindContext() : base("name=NorthwindEntities", 

"NorthwindEntities")

            _categories = CreateObjectSet<Category>();

            _products = CreateObjectSet<Product>();

        public ObjectSet<Category> Categories

get

                return _categories;

        private ObjectSet<Category> _categories;

        public ObjectSet<Product> Products

get

                return _products;

        private ObjectSet<Product> _products;

注意，ObjectSet<T> 是Entity Framework 4.0中引进的一个特殊的ObjectQuery<T>。

就这么简单！现在你有了纯粹的POCO实体，一个简单的上下文，允许你编写象这样的查询：

    NorthwindContext db = new NorthwindContext();

    var beverages = from p in db.Products

                    where p.Category.CategoryName == "Beverages"

                    select p;

从数据库中复原的实体是纯粹的POCO实体，你可以对这些实体做变动，将变动保存到数据库中，跟平常的EntityObject或IPOCO实体非常类似。你将得到实体框架提供的所有服务，唯一的区别是，你现在使用的是纯粹的POCO实体。

就我们的简化了的例子而言，尚有无数改进的可能性。但在那之前，我想先把一些基本的问题解决掉。

在使用POCO之前我需要一个实体数据模型么？

是的，Entity Framework 4.0中的POCO支持只是去除了在你的实体类中带特定于持久性的关注的需求而已。但还是需要你提供CSDL/SSDL/MSL (总称EDMX)元数据，这样实体框架才能够将你的实体和元数据结合起来，以允许你访问数据。我们还在另外开发一个东西，它允许你做真正的“代码优先（code-first）”的开发，而不需要预先定义好的EDMX模型。这个功能的社区预览版将在几个月内在网上发布，一有机会我们就会将其加入实体框架。一如既往，你的反馈对我们极其有用。

我始终都只能手写这些实体和上下文么？

不， Entity Framework 4.0中有一个非常强大和灵活的代码生成机制，该机制是基于T4之上的（Alex曾在这里的博客上讨论过）。你可以提供你自己的模板，允许你按照你自己选择的方式建造实体。我们还在努力，以提供一些标准的模板，可为你生成POCO实体。

使用POCO实体时，元数据是怎么映射的？

在Entity Framework 3.5中，基于EntityObject和IPOCO的实体都是依赖着使用映射特性（attributes），对实体类型和属性进行修饰和映射到概念性模型中对应的元素的。Entity Framework 4.0 引入了基于约定（convention）的映射，以允许不用显式的修饰，就可将实体类型，属性，复杂类型和关系映射到概念性模型。一个简单的规则是，在你的POCO类中使用的实体类型名称，属性名称，和复杂类型名称必须匹配那些在概念性模型中定义了的相应名称。命名空间的名称不在考虑之中，类中的命名空间定义和概念性模型中的命名空间定义不必相符。

我的实体类中的所有属性都需要有公开的getters和setters么？

你可以在你的POCO类型的属性上使用任何访问控制修饰符（access modifier），只要被映射的任何属性都不是虚拟的，以及你不需要局部信任（partial trust）支持。在局部信任下运行时，对你的实体类的访问控制修饰符的可见性有一些特定的要求。我们将对在涉及局部信任时，所支持的完整的访问控制修饰符集提供详细的文档。

对基于集合的导航属性都支持哪些集合类型？

任何属于ICollection<T>的类型都是支持的。如果你对ICollection<T>类型的字段不以具体的类型初始化的话，那么从数据库中复原实体集合时，将提供List<T>。

我可以有单向的关系么？例如，我想在我的Product类中有一个 Category 属性，但在Category类中我不想要一个Products集合。

是的，这是支持的。唯一的限制是，你的实体类型必须反映模型中所定义的东西。如果你不想拥有对应于关系的某一边的导航属性的话，那么你需要从模型中将其完全剔除。

POCO支持延迟（懒式）装载么？

是的，POCO是通过使用代理类型来支持延迟（懒式）装载的，这些代理类型是在你的POCO类之上提供自动的懒式装载行为的。在讨论到延迟装载时，我们会对此做详述，在那之前，知道一下我们也支持通过使用“Include”来实现的早期装载（eager loading），象这样：

var beverageCategory = (from c in context.Categories

.Include("Products")

                        where c.CategoryName == "Beverages"

                        select c).Single();

如果我要使用延迟（懒式）装载的话，我不用这么做，在讨论代理时我们会对此进行讨论。

修整（fix-up）关系

要了解有2种类型的修整：1)查询时的修整, 2) 对你的实体/关系进行改动时的修整。

查询时的修整

查询时的修整是在同一个ObjectContext上使用不同的查询来装载相关的实体时发生的。例如，如果我查询了一个分类实例“Beverages（饮料）”，之后又查询一个产品实例“Chai”（是在Beverages分类中的），我想要chai.Category 指向Beverages分类实例，不用我做额外的工作。

这在今天是自动的，而且已经工作。

对你的实体/关系进行改动时的修整

这是在添加/去除与另一个实体相关的实体或者改变关系时两个实体间的关系修整。设想一下这样的例子：在我创建一个名叫“Diet Chai”的新产品时，我想要将其与Beverages 分类相关联。

在Entity Framework 4.0 Beta1 中，在这种情形下，POCO实体得不到自动的关系修整。在处理实体间的关系变动时，你需要确认你的POCO类型包含了在关系两头正确处理关系修整的逻辑。

例如，在我的Northwind例子中，我在Category上定义了如下的方法，以支持添加/去除订单。

        public void AddProduct(Product p)

            if (Products == null)

                Products = new List<Product>();

            if (!Products.Contains(p))

                Products.Add(p);

            p.Category = this;

总的来说，使用象这样的模式来支持添加/去除相关项，要比使用关系集合来添加/去除相关实体为好。你还可以选择将实际由EF支持的集合的getter/setter变成私有或内部访问控制，来支持更为细颗粒的访问，但就象前面提到的那样，其中一些东西取决于你是否需要局部信任支持这样的需求。

我们在这个“简短的综述”中对总的POCO体验做了一番讨论。要讨论的东西还有很多很多，下个星期我将继续这个讨论。与此同时，请看一下附件中的完整解决方案，如果你对我们在这里讨论的所有概念的相应例程代码感兴趣的话。请记住，你必须在运行这个例程的机器上安装一个本地Northwind数据库。

在下一个贴子中，我们将看一下复杂类型，变化跟踪，代理，懒式装载和早期装载。在那之前，请阅读一下MSDN这里的关于POCO的文档，以了解Entity Framework 4.0中的POCO支持的细节。

请告知我们你们的想法！

Faisal Mohamood
Entity Framework的Program Manager

附件： NorthwindPocoSamplePart1.zip

复杂类型（Complex Types）

POCO中的复杂类型支持跟常规的基于EntityObject的实体中的复杂类型支持一样。你要做的就是将它们声明为POCO类，然后在你的POCO实体中使用和声明基于它们的属性。

作为例子，这里是一个InventoryDetail复杂类型，代表我的Product实体的一个部分：

public class InventoryDetail

{

    public Int16 UnitsInStock { get; set; }

    public Int16 UnitsOnOrder { get; set; }

    public Int16 ReorderLevel { get; set; }

}

把我的Product类修改成包含一个这个类型的属性，用来组合几个有关库存细节的字段：

public class Product

{

    public int ProductID { get; set; }

    public string ProductName { get; set; }

    public int SupplierID { get; set; }

    public string QuantityPerUnit { get; set; }

    public decimal UnitPrice { get; set; }

    public InventoryDetail InventoryDetail { get; set; }

    public bool Discontinued { get; set; }

    public Category Category { get; set; }

}

然后你可以做你以前对复杂类型所能做的一切，这是一个查询的例子：

var outOfStockProducts = from c in context.Products

                         where c.InventoryDetail.UnitsInStock == 0

                         select c;

你可以看到，POCO中的复杂类型支持用起来非常直截了当。但在POCO中使用复杂类型支持时，你需要记住几件事情：

你必须将复杂类型定义为类（class），结构体（struct）是不支持的。
在你的复杂类型类中，你不能使用继承。

既然在讨论复杂类型，我想我要提一下另外一件事，你知道Visual Studio 2010中的实体框架设计器支持复杂类型的声明么？

在Visual Studio 2008中，你只能手工将复杂类型的声明加到CSDL中去，但随着Visual Studio 2010中的设计器中对复杂类型支持的推出，这一切都成了历史。

更酷的是，因为Visual Studio 2010支持多定向（Multi-Targeting），你可以在开发针对.NET Framework 3.5，使用了Entity Framework 3.5的应用中也使用这个功能！

延迟/懒式装载

在我2个星期前发表的《延迟装载初览》一文中，我提到了实体框架现在支持延迟装载了。默认的、代码生成的基于EntityObject的实体类型将提供延迟装载，自然毫不奇怪。如果你想知道POCO对象中是否也支持延迟装载，那么我想，你会很高兴地知道，你在POCO中也能得到延迟装载支持。

为在POCO实体中使用延迟装载支持，你需要做2件事情：

将你想要懒式装载的属性声明为virtual，这些属性可以是任何实现了ICollection<T> 的集合类，或者它们可以是代表了1/0..1 关系的引用。

例如，这里是更新过的Category实体类的部分代码，我将其改成支持延迟装载了：

public class Category

{

    public int CategoryID { get; set; }

    public string CategoryName { get; set; }

    public string Description { get; set; }

    public byte[] Picture { get; set; }

    public virtual List<Product> Products { get; set; }

    ...

2. 在上下文中启用延迟装载选项：

context.ContextOptions.DeferredLoadingEnabled = true;

这就行了，你现在就将得到POCO类型的自动延迟装载，而不用做任何其他什么事情。

那么这玩意到底是怎么工作的，底层是怎么进行的？

这玩意能工作的原因是因为，在我将集合类型的属性标记为virtual后，这允许实体框架在运行时为我的POCO类型提供一个代理（proxy）实例，正是这个代理实现了自动的延迟装载。该代理实例是基于一个继承自我的POCO实体类的类型，所以你提供的所有功能都被保留下来了。从开发人员的角度来看，即使延迟装载或许是个需求，这也允许你编写透明持久性的代码。

如果你在调试器中检查实际的实例时，你会看到该实例的底层类型与我原先声明的类型是不同的：

虽然实体框架尽力以最小的摩擦提供自动的延迟装载，但在处理你想要添加或附加手工生成的实例时，或者当你序列化/发序列化实例时，这是你需要知道的事情。

为POCO实体手工生成代理实例

为了允许可以添加或附加的代理实例的生成，你可以使用ObjectContext上的CreateObject工厂方法来生成实体实例：

Category category = context.CreateObject<Category>();

要把这个记住，在生成你想要用于实体框架的实例时，要使用CreateObject。

用“变动跟踪代理（Change Tracking Proxies）”来提供更有效的变动跟踪

到目前为止，我们讨论过的标准POCO实体都依赖于基于快照（snapshot）的变动跟踪，即，实体框架会保管实体变动之前的值和关系的快照，这样，在保存（Save）时，可以与当前的值做比较。但这个比较的花销是相当大的，如果跟基于EntityObject的实体的变动跟踪的方式相比的话。

还有另外一种类型的代理，它允许你在使用POCO实体时得到比较好的变动跟踪性能。

如果你熟悉IPOCO接口，你知道IEntityWithChangeTracker是要求你在类中实现、来向实体框架提供变动通知的接口之一。

变动跟踪代理从你的POCO实体类继承而来，在运行时给你提供这个功能，而不要求你自己实现IPOCO接口。

从许多方面讲，用这种方式的话，你是鱼与熊掌都兼得了：你得到了POCO类的透明持久性，在变动跟踪方面你也得到了EntityObject / IPOCO 的性能。

为了得到变动跟踪代理，基本的规则是，你的类必须是公开的，非抽象的或者非密封的（non-sealed）。你的类对所有要持久的属性都必须实现公开的virtual getters/setters。最后，你必须将基于集合的关系导航属性严格声明为ICollection<T>。它们不能是具体的实现或者继承自ICollection<T>的另外的接口（与延迟装载代理有所不同）。

这里是我的Product POCO类的例子，它将在运行时给我提供更有效的基于代理的变动跟踪：

public class Product

{

    public virtual int ProductID { get; set; }

    public virtual string ProductName { get; set; }

    public virtual int SupplierID { get; set; }

    public virtual string QuantityPerUnit { get; set; }

    public virtual decimal UnitPrice { get; set; }

    public virtual InventoryDetail InventoryDetail { get; set; }

    public virtual bool Discontinued { get; set; }

    public virtual Category Category { get; set; }

}

再说一遍，要记住，如果你要将实体加到或附加到上下文的话，你必须使用CreateObject来生成代理实例。但不依赖代理的纯粹的POCO实体和基于代理的实体可以共处。你只有在涉及基于代理的实体时才需使用CreateObject。

如果我想在同个POCO类型中同时启用延迟装载和更好的变动跟踪，该怎么办？

这两个东西不是互相排斥的，你不必在延迟装载代理和变动跟踪代理间做选择。如果你想要延迟装载，以及有效的变动跟踪，你只要按照变动跟踪代理的规则办，以及启用延迟装载选项。变动跟踪代理会给你提供延迟装载，如果延迟装载选项是启用了的话。

显式装载

这个延迟装载的功能确实很棒，但你们中很多人大概想要完全控制你是如何装载相关实体的吧。你甚至会选择走纯粹的POCO之路，而不诉诸于任何自动代理生成能给你提供的功能。

这是完全可以接受的，（在很多情形下也许是更好的方法），你可以使用显式关系装载，对你是如何在数据库中查询数据的做完全的控制。

在POCO中做显式装载，有2个选项：

一个是使用 ObjectContext.LoadProperty ，设置你想要装载的导航属性的名称：

context.LoadProperty(beveragesCategory, "Products");

这是可行的，但你可以看出来，这并不类型安全（type safe）。如果我没有正确的导航属性的名称的话，我会得到一个运行时异常。

你们中的一些人大概更喜欢这个：

context.LoadProperty(beveragesCategory, c => c.Products);

我可以使用lambda表达式来指定我想要显式装载的属性，这提供了更好的类型安全。

上面是我计划在这第二个贴子里讨论的所有的内容了。但以后还会有更多内容，在这个系列的最后一篇里，我们将讨论在处理纯POCO（非代理化的）实例以及在你的对象图和对象状态管理器（Object State Manager）间保持一致时需要知道的几件事情。我们也会讨论你也许想要知道的SaveChanges方法的多个变种。

与此同时，请看一下我更新过的样例代码，其中包括了我们在本贴里讨论过的一些东西。

Faisal Mohamood
Entity Framework的Program Manager

附件: NorthwindPocoSamplePart2.zip

Implementing Audit Trail using Entity Framework

2009-05-31T02:25:21Z

Download source - 248.75 KB

Introduction

Entity framework keeps track of those entire objects and relationships which have been deleted, added and modified in the container. EF keeps the state of the object and holds the necessary change-information and all the track information for each object or relationship resides as objectStateEntry. Using ObjectStateManager, one can access all this change-information like object-state (added/modified/deleted), modified properties, original and current values and can easily do audit trail for those objects. To get the Rollback feature from that audit trail, we have to consider some issues. We have to maintain the order of entity graph while doing insertion and deletion. That means root entity has been inserted before the children and during deletion we have to make it reverse. The most important issue is that we have to make sure that audit trail entry will be inserted according to this order.

So now I am going to talk about audit trail implementation that’s capable to rollback to a certain period. To make such an implementation, I am going to use the Entity framework’s caching Management that is called ObjectStateManager. Using this manager, I will be capable of finding out the object that is currently changed or added or deleted and resides in EF cache as Object state entry. In part 1, I am just going to talk about creating audit trail objects using the object state entry. In Part II, we will talk about roll back feature of this audit trial.

Using the Code

First, I make the table audit trail in the database:

For this table, I am going to make an Entity set in my conceptual level as:

In Entity Framework, to save all my changes into database, we have to call Context.SaveChanges() and this context is a container that has been inherited from ObjectContext class.To create the Audit trail Objects for each “Modified/Added/Deleted”, I am going to catch the event:

Context.SavingChanges +=new EventHandler(Context_SavingChanges);

In the sample program, I have done it by writing partial class:

public partial class AdventureWorksEntities
{ partial void OnContextCreated()
{
    this.SavingChanges += new EventHandler(AdventureWorksEntities_SavingChanges);
}

void AdventureWorksEntities_SavingChanges(object sender, EventArgs e)
{

So in my AdventureWorksEntities_SavingChanges method, I am going to create all dbaudit objects that are going to save in DB. Here it takes each entry from EF cache of state- Added or Deleted or Modified and calls a factory method to produce audit trail object.

public partial class AdventureWorksEntities
{
    public string UserName { get; set; }
    List<DBAudit> auditTrailList = new List<DBAudit>();

    public enum AuditActions
    {
        I,
        U,
        D
    }

    partial void OnContextCreated()
    {
        this.SavingChanges += new EventHandler(AdventureWorksEntities_SavingChanges);
    }

    void AdventureWorksEntities_SavingChanges(object sender, EventArgs e)
    {
        IEnumerable<ObjectStateEntry> changes = 
            this.ObjectStateManager.GetObjectStateEntries(
            EntityState.Added | EntityState.Deleted | EntityState.Modified);
        foreach (ObjectStateEntry stateEntryEntity in changes)
        {
            if (!stateEntryEntity.IsRelationship &&
            stateEntryEntity.Entity != null &&
            !(stateEntryEntity.Entity is DBAudit))
            {//is a normal entry, not a relationship
                DBAudit audit = this.AuditTrailFactory(stateEntryEntity, UserName);
                auditTrailList.Add(audit);
            }
        }

        if (auditTrailList.Count > 0)
        {
            foreach (var audit in auditTrailList)
            {//add all audits 
                this.AddToDBAudit(audit);
            }
        }
    }

And here AuditTrailFactory is a Factory method to create dbaudit object.Specially for the Modify state, it keeps the modified properties and is serialized as XML. So using these fields, you can easily show the changes of modified object by doing any comparison of old and new data.

private DBAudit AuditTrailFactory(ObjectStateEntry entry, string UserName)
{
    DBAudit audit = new DBAudit();
    audit.AuditId = Guid.NewGuid().ToString();
    audit.RevisionStamp = DateTime.Now;
    audit.TableName = entry.EntitySet.Name;
    audit.UserName = UserName;

    if (entry.State == EntityState.Added)
    {//entry is Added 
        audit.NewData = GetEntryValueInString(entry, false);
        audit.Actions = AuditActions.I.ToString();
    }
    else if (entry.State == EntityState.Deleted)
    {//entry in deleted
        audit.OldData = GetEntryValueInString(entry, true);
        audit.Actions = AuditActions.D.ToString();
    }
    else
    {//entry is modified
        audit.OldData = GetEntryValueInString(entry, true);
        audit.NewData = GetEntryValueInString(entry, false);
        audit.Actions = AuditActions.U.ToString();

        IEnumerable<string> modifiedProperties = entry.GetModifiedProperties();
        //passing collection of mismatched Columns name as serialized string 
        audit.ChangedColumns = XMLSerializationHelper.XmlSerialize(
            modifiedProperties.ToArray());
    }

    return audit;
}

Here GetEntryValueInString is for creating XML text of previous or modified object. In Entity Framework, each entry holds all change definition. First I make a clone of the current object. Using entry.GetModifiedProperties(), I can get only modified properties of an object and using OriginalValues and CurrentValues, I can build myself the old data and new data. Factory has told me what that wants – old or new. At the end, I have serialized XML and return back XML string.

private string GetEntryValueInString(ObjectStateEntry entry, bool isOrginal)
{
    if (entry.Entity is EntityObject)
    {
        object target = CloneEntity((EntityObject)entry.Entity);
        foreach (string propName in entry.GetModifiedProperties())
        {
            object setterValue = null;
            if (isOrginal)
            {
                //Get original value 
                setterValue = entry.OriginalValues[propName];
            }
            else
            {
                //Get original value 
                setterValue = entry.CurrentValues[propName];
            }
            //Find property to update 
            PropertyInfo propInfo = target.GetType().GetProperty(propName);
            //update property with original value 
            if (setterValue == DBNull.Value)
            {//
                setterValue = null;
            }
            propInfo.SetValue(target, setterValue, null);
        }//end foreach

        XmlSerializer formatter = new XmlSerializer(target.GetType());
        XDocument document = new XDocument();

        using (XmlWriter xmlWriter = document.CreateWriter())
        {
            formatter.Serialize(xmlWriter, target);
        }
        return document.Root.ToString();
    }
    return null;
}

To clone the entity, I have used the method which I have found in an MSDN forum post (Thanks to Patrick Magee):

public EntityObject CloneEntity(EntityObject obj)
{
    DataContractSerializer dcSer = new DataContractSerializer(obj.GetType());
    MemoryStream memoryStream = new MemoryStream();

    dcSer.WriteObject(memoryStream, obj);
    memoryStream.Position = 0;

    EntityObject newObject = (EntityObject)dcSer.ReadObject(memoryStream);
    return newObject;
}

That is all for Part 1 where I just create the Audit trail objects for each CUD operation.

· Download source - 317.88 KB

Introduction

I talked about creating audit trail objects using the object state entries. As I said earlier, in the second part I will talk about roll back feature of this audit trail. In the first part, I already described that to get the Rollback feature from that audit trail, we have to consider some issues. We have to maintain the order of entity graph while inserting and deleting. That means the root entity has been inserted before the children and during deletion, we have to reverse it. The most important issue is that we have to make sure that each audit trail entry has been inserted according to this order. So during insertion of object, we also need to consider these things:

Maintain insertion date-time to sort the audit trial
Store the old data and new data
Store the state of the data as audit action

If user chooses a certain time to roll back, we have to start with last audits and do the roll back action for each audit till a certain time. So now the question is what the roll back action will be. You can guess that it’s depending on the Audit action of each entity. During rollback:

Inserted data will be deleted.
Deleted data will be inserted.
Modified data will be replaced by the old one.

If we see the conceptual model, our Entity set for Audit was:

Here “RevisionStamp” holds the audit insertion date-time, Actions hold the audit action of the entity object (Insert/deleted/modified). Other properties describe themselves with their names.

So here “Deleted” and “Modified” objects will be rolled back with “Old data” property. And Inserted data will be rolled back with “New data” property.

Using the Code

So first, I am going to retrieve all the audits that happen after a specific date-time. This specific date-time is taken from the user. What we have to do is, rollback action for each audit till a specific date and we have to start with the last one (bottom to top). That is why we are going to sort the audit with “RevisionStamp” in a descending order and start doing rollback.

public static bool RollBack(DateTime rollBackDate, string userName)

{

using (TransactionScope transactionScope =

new TransactionScope(System.Transactions.TransactionScopeOption.Required,

TimeSpan.FromMinutes(30)))

{

AdventureWorksEntities context =new AdventureWorksEntities();

try

{

if (context.Connection.State != ConnectionState.Open)

{//Open the connection

context.Connection.Open();

}//end if

//find all audits to roll back

IEnumerable<DBAudit> auditsToRollBack = DataAdapter.GetEntity

<DBAudit>(context, a => a.RevisionStamp >= rollBackDate );

if (null != auditsToRollBack && auditsToRollBack.Count() > 0)

{//if any data found to roll back

//Order by the audits by creation datetime

IEnumerable<DBAudit> orderedAudits =

auditsToRollBack.OrderByDescending(a => a.RevisionStamp);

foreach (var audit in orderedAudits)

{//iterate each audit

AuditTrailHelper.DoRollBackAction(ref context, audit, userName);

}//end foreach

int i =context.SaveChanges();

if (i > 0)

{

transactionScope.Complete();

return true;

}

catch (Exception ex)

{

throw ex;

}

finally

{

// Explicitly dispose of the context,

// which closes the connection.

context.Dispose();

}

return false;

}

In DoRollBackAction as I said before, “Deleted” and “Modified” objects will be rolled back with “Old data” property. And Inserted data will be rolled back with “New data” property.

As I stored old data and new data with XML Serialization while creating the Audit object, I have to deserialise that data into “EntityObject” and do the reverse action according to the audit action.

private static void DoRollBackAction

(ref AdventureWorksEntities context, DBAudit auditInfo, string userName)

{

if (auditInfo.Actions == AuditTrailHelper.AuditActions.U.ToString() ||

auditInfo.Actions == AuditTrailHelper.AuditActions.D.ToString())

{//For action of Update and Delete

//Deserialized old data from the XML

object oldData = AuditTrailHelper.GetAuditObjectFromXML

(auditInfo.OldData, auditInfo.TableName);

if (oldData is EntityObject)

{

EntityObject oldEntity = (EntityObject)oldData;

oldEntity.EntityKey = null;

//add in case of delete or edit the current one with old data

DataAdapter.EditEntity(ref context, oldEntity);

}

else if (auditInfo.Actions == AuditTrailHelper.AuditActions.I.ToString())

{//For Insert Action

object newData = AuditTrailHelper.GetAuditObjectFromXML

(auditInfo.NewData, auditInfo.TableName);

if (newData is EntityObject)

{

//Otherwise, delete the entity that has been inserted before

EntityObject newEntity = (EntityObject)newData;

newEntity.EntityKey = null;

EntityKey key = context.CreateEntityKey

(newEntity.GetType().Name, newEntity);

object objToRemoved = null;

if (context.TryGetObjectByKey(key, out objToRemoved))

{//delete the entity

context.DeleteObject(objToRemoved);

}//end if

}

//delete the audit

context.DeleteObject(auditInfo);

}

After serializing the entity Object, we get the XML string like this:

<SalesOrderDetail xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<EntitySetName>SalesOrderDetail</EntitySetName>

<EntityContainerName>AdventureWorksEntities</EntityContainerName>

</EntityKey>

<EntitySetName>SpecialOfferProduct</EntitySetName>

<EntityContainerName>AdventureWorksEntities</EntityContainerName>

<Key>SpecialOfferID</Key>

</EntityKeyMember>

<Key>ProductID</Key>

</EntityKeyMember>

</EntityKeyValues>

</EntityKey>

</SpecialOfferProductReference>

</SalesOrderDetail>

I have to deserialize this XML string. During deserializing, I have created an XML document and an XML reader using that document. Using that reader, I deserialized the entity object. The method to deserialize the entityobject is:

public static object GetAuditObjectFromXML(string ObjectInXML, string typeName)

{

XDocument doc = XDocument.Parse(ObjectInXML);

//Assuming doc is an XML document containing a

//serialized object and objType is a System.Type set to the type of the object.

XmlReader reader = doc.CreateReader();

//get the Type of entity object

Type entityType = Assembly.GetExecutingAssembly().GetType

("ImplAuditTrailUsingEF." + typeName);

XmlSerializer ser = new XmlSerializer(entityType);

return ser.Deserialize(reader);

}

For inserting deleted object or to change back modified object, I wrote a single method to edit the object:

EditEntity(ref AdventureWorksEntities context, EntityObject entity)

Is this method, I change the existence object and attach it to the container otherwise I have inserted the entityObject into the context. To save all of this change, we need an entry in Object state cache.

public static void EditEntity

(ref AdventureWorksEntities context, EntityObject entity)

{

// Define an ObjectStateEntry and EntityKey for the current object.

EntityKey key;

object originalItem;

// Get the detached object's entity key.

if (entity.EntityKey == null)

{

// Get the entity key of the updated object.

key = context.CreateEntityKey(entity.GetType().Name, entity);

}

else

{

key = entity.EntityKey;

}

try

{

// Get the original item based on the entity key from the context

// or from the database.

if (context.TryGetObjectByKey(key, out originalItem))

{//accept the changed property

// Call the ApplyPropertyChanges method to apply changes

// from the updated item to the original version.

context.ApplyPropertyChanges(

key.EntitySetName, entity);

}

else

{//add the new entity

context.AddObject(entity.GetType().Name, entity);

}//end else

}

catch (System.Data.MissingPrimaryKeyException ex)

{

throw ex;

}

catch (System.Data.MappingException ex)

{

throw ex;

}

catch (System.Data.DataException ex)

{

throw ex;

}

That is all for implementing rollback mechanism in our audit trail. Now all we have to do is just call the “RollBack” method and give it a specific date to roll back.

private void btnRollBack_Click(object sender, RoutedEventArgs e)

{

if (AuditTrailHelper.RollBack(dtpRollBackDate.SelectedDate.Value, "Admin"))

{

MessageBox.Show("Successfully Roll Backed!!");

}

That’s all for implementation of Audit trial with entity framework. Here I have deleted the audits which have been rolled back. Definitely each rollback operation is also a DB operation and I did an audit for each rollback operation.

Is the sample project, I have used the free version of Xeed. You may need to download that Library, otherwise you can replace it with the WPF toolkit. It has just been used for getting a date-time from user to rollback.

POCO in the Entity Framework - The Experience

2009-05-31T02:16:07Z

Last week I mentioned in the sneak preview on POCO that support for POCO entities is one of the new capabilities we have added to Entity Framework 4.0. This week, I’d like to go into the details of POCO support in Entity Framework 4.0.

There’s quite a bit to discuss here, including:

Overall POCO experience in Entity Framework 4.0
Change Tracking in POCO
Relationship Fix-up
Complex Types
Deferred (Lazy) Loading and Explicit Loading
Best Practices

In this post, I will focus primarily on the overall experience so that you can get started with POCO in Entity Framework 4.0 right away. I’d like to use a simple example that we can walk through so you can see what it feels like to use POCO in Entity Framework 4.0. I will use the Northwind database, and we’ll continue to build on this example in subsequent posts.

Step 1 – Create the Model, turn off default Code Generation

While POCO allows you to write your own entity classes in a persistence ignorant fashion, there is still the need for you to “plug in” persistence and EF metadata so that your POCO entities can be materialized from the database and persisted back to the database. In order to do this, you will still need to either create an Entity Data Model using the Entity Framework Designer or provide the CSDL, SSDL and MSL metadata files exactly as you have done with Entity Framework 3.5. So first I’ll generate an EDMX using the ADO.NET Entity Data Model Wizard.

Create a class library project for defining your POCO types. I named mine NorthwindModel. This project will be persistence ignorant and will not have a dependency on the Entity Framework.
Create a class library project that will contain your persistence aware code. I named mine NorthwindData. This project will have a dependency on Entity Framework (System.Data.Entity) in addition to a dependency on the NorthwindModel project.
Add New Item to the NorthwindData project and add an ADO.NET Entity Data Model called Northwind.edmx (doing this will automatically add the dependency to the Entity Framework).
Go through “Generate from Database” and build a model for the Northwind database.
For now, select Categories and Products as the only two tables you are interested in adding to your Entity Data model.

Now that I have my Entity Data model to work with, there is one final step before I start to write code : turn off code generation. After all you are interested in POCO – so remove the Custom Tool that is responsible for generating EntityObject based code for Northwind.edmx. This will turn off code generation for your model.

We are now ready to write our POCO entities.

Step 2 – Code up your POCO entities

I am going to write simple POCO entities for Category and Product. These will be added to the NorthwindModel project. Note that what I show here shouldn’t be taken as best practice and the intention here is to demonstrate the simplest case that works out of the box. We will extend and customize this to our needs as we go forward and build on top of this using Repository and Unit of Work patterns later on.

Here’s sample code for our Category entity:

    public class Category
    {
        public int CategoryID { get; set; }
        public string CategoryName { get; set; }
        public string Description { get; set; }
        public byte[] Picture { get; set; }
        public List<Product> Products { get; set; }
    }

Note that I have defined properties for scalar properties as well as navigation properties in my model. The Navigation Property in our model translates to a List<Product>.

Similarly, Product entity can be coded like this:

    public class Product
    {
        public int ProductID { get; set; }
        public string ProductName { get; set; }
        public int SupplierID { get; set; }
        public string QuantityPerUnit { get; set; }
        public decimal UnitPrice { get; set; }
        public Int16 UnitsInStock { get; set; }
        public Int16 UnitsOnOrder { get; set; }
        public Int16 ReorderLevel { get; set; }
        public bool Discontinued { get; set; }
        public Category Category { get; set; }
    }

In this case, since the relationship allows only one Category that a Product can belong to, we have a reference to a Category (unlike the List<T> collection we have for modeling the Navigation Property in Category).

Step 3 – Code up your Entity Framework Context

The last thing I have to do in order to pull all of this together is to provide a context implementation (much like the ObjectContext implementation you get when you use default code generation). The context is the glue that brings persistence awareness into your application, and it will allow you to compose queries, materialize entities as well as save changes back to the database. The context will be a part of the NorthwindData project.

For simplicity, I will include our context into the same class library that has our entity types – but when we discuss patterns such as Repository and Unit of Work, we will set it up such that you have a pure POCO class library without any persistence concerns.

Here’s a simple context implementation for our scenario:

public class NorthwindContext : ObjectContext
    {   
        public NorthwindContext() : base("name=NorthwindEntities", 
"NorthwindEntities")  
        {
            _categories = CreateObjectSet<Category>();
            _products = CreateObjectSet<Product>();
        }

        public ObjectSet<Category> Categories
        {
            get 
            { 
                return _categories; 
            }
        }
        private ObjectSet<Category> _categories;

        public ObjectSet<Product> Products
        {
            get
            {
                return _products;
            }
        }
        private ObjectSet<Product> _products;
    }

Note that ObjectSet<T> is a more specialized ObjectQuery<T> that we introduced in Entity Framework 4.0.

That’s it – now you have pure POCO entities with a simple context that will allow you to write queries like this:

    NorthwindContext db = new NorthwindContext();

    var beverages = from p in db.Products
                    where p.Category.CategoryName == "Beverages"
                    select p;

The entities that are materialized are pure POCO entities, and you can make and persist changes much like you would with regular EntityObject or IPOCO entities. You get all the services provided by Entity Framework - the only difference is that you are using pure POCO entities.

There are many possibilities here as far as how we can improve on this simplified example. Before we get into that however, I would like to get some basic questions out of the way.

Do I need an Entity Data Model before I can use POCO?

Yes – POCO support in Entity Framework 4.0 simply removes the need of having persistence specific concerns in your entity classes. There is still the need for you to have a CSDL/SSDL/MSL (collectively EDMX) metadata so that the Entity Framework is able to use your entities along with the metadata in order to enable data access. There is a separate effort that we are working on that will allow you to do true “code-first” development without the need to have a predefined EDMX model. A community preview of this feature will be released to the web in the coming months. We will roll this into the product the first chance we get. As always, your feedback will be helpful.

Do I have to always hand-craft these entities and the context?

No – there is a very powerful and flexible code generation mechanism in Entity Framework 4.0 that is based on T4 as Alex blogged about here. You can provide your own templates that allow you to build your entities in a way that you see fit. We are also working on providing standard out of the box templates that will generate POCO entities for you.

How is metadata mapped when using POCO entities?

In Entity Framework 3.5, both EntityObject and IPOCO based entities relied on the use of mapping attributes that were meant for decorating and mapping the entity types and properties back to the corresponding elements in the Conceptual model. Entity Framework 4.0 introduces convention based mapping for allowing mapping of Entity Types, Properties, Complex Types and Relationships back to the conceptual model without the need for explicit decoration. The simple rule here is that Entity Type names, Property names and Complex Types names used in your POCO classes must match those defined by the conceptual model. Namespace names are ignored and don’t have to match between the class definition and the conceptual model.

Do I need to have public getters and setters for all properties in my entity classes?

You can use any access modifier on your POCO type’s properties as long as none of the mapped properties are virtual and as long as you don’t require partial trust support. When running in partial trust, there are specific requirements on the visibility of access modifiers on your entity classes. We will be documenting the complete set of access modifiers that are supported when partial trust is involved.

What types of collections are supported for collection based navigation properties?

Any collection that is an ICollection<T> will be supported. If you don’t initialize the field with a concrete type that is an ICollection<T> type, then an List<T> type will be provided upon materialization.

Can I have uni-directional relationships? For instance – I would like to have a Category property in my Product class, but I don’t want to have a Products collection in my Category class.

Yes – this is supported. The only restriction here is that your entity types have to reflect what is defined by the model. If you are not interested in having the navigation property for one side of the relationship, then remove it from the model completely.

Is Deferred (Lazy) Loading supported with POCO?

Yes – Deferred (Lazy) loading is supported with POCO through the use of proxy types that are used to provide automatic lazy loading behavior on top of your POCO classes. This is something that we’ll cover when we get to deferred loading – until then know that eager loading via the use of “Include” is also supported, like so:

var beverageCategory = (from c in context.Categories
.Include("Products")
                        where c.CategoryName == "Beverages"
                        select c).Single();

If I were to use Deferred (Lazy) Loading, I don’t have to do this – we’ll discuss that when we discuss proxies.

Fixing up Relationships

There are two types of fix-ups to be aware of: 1)Fix-up during query, and 2) Fix-up during changes to your entities/relationships

Fix-up during Query

Fix-up during query happens when you load related entities using separate queries on the same ObjectContext. For instance, if I were to query for a category instance Beverages, and later query for a product instance Chai (that is in Category Beverages), I would want chai.Category to point to the instance of the Beverages category without additional work.

This is automatic and works today.

Fix-up during changes to your entities/relationships

This is the relationship fix-up between two entities when I add/remove an entity that is related to another entity or alter relationships. Think of this as the case when I create a new product called “Diet Chai” and want to associate it with the Beverages category.

In Beta1 of Entity Framework 4.0, you do not get automatic relationship fix-up in this case with POCO entities. When dealing with relationships that change between entities, you will have to make sure that your POCO types include the logic to manage fix-up on both ends of the relationship correctly.

For instance, in my Northwind example, I have defined the following method on Category to support adding / removing of Orders.

        public void AddProduct(Product p)
        {
            if (Products == null)
            {
                Products = new List<Product>();
            }

            if (!Products.Contains(p))
            {
                Products.Add(p);
            }            
            
            p.Category = this;
        }

In general, it is good to use a pattern like this to support adding/removing related items rather than using the relationship collection to add/remove related entities. You also have options of making the getter/setter for the actual EF backed collection private/internal to support more fine grained access – but as mentioned earlier, some of this depends on the requirements as to whether you require partial trust support or not.

So we have covered quite a bit of ground in this “quick look” at the overall POCO experience. There’s quite a lot more to talk about – and I will be continuing this discussion early next week. In the meantime, take a look at the complete solution (attached) if you are interested in the sample code covering all the concepts we covered here. Please keep in mind that you must have a local instance of Northwind database installed on the machine where you are running this sample.

In my next post we will look at Complex Types, Change Tracking, Proxies, Lazy Loading and Eager Loading. Until then, please look through the MSDN Documentation on POCO here for more details on POCO support in Entity Framework 4.0.

Let us know what you think!

Faisal Mohamood
Program Manager, Entity Framework

Filed under: Entity Framework

Attachment(s): NorthwindPocoSamplePart1.zip

Complex Types, Deferred Loading and Explicit Loading

Published 28 May 09 09:03 AM | dpblogs

In my post last week on the POCO Experience in Entity Framework, I covered the fundamentals of POCO support in Entity Framework 4.0. In this post, I’ll cover a few more aspects related to POCO.

Complex Types

Complex Types are supported in POCO just like they are with regular EntityObject based entities. All you have to do is declare your complex types as POCO classes and then use them for declaring the complex type based properties on your POCO entities.

As an example, here’s an InventoryDetail complex type to represent a part of my Product entity:

public class InventoryDetail
{
    public Int16 UnitsInStock { get; set; }
    public Int16 UnitsOnOrder { get; set; }
    public Int16 ReorderLevel { get; set; }
}

My Product class now has been modified to include a property of this type to group the inventory detail fields:

public class Product
{
    public int ProductID { get; set; }
    public string ProductName { get; set; }
    public int SupplierID { get; set; }
    public string QuantityPerUnit { get; set; }
    public decimal UnitPrice { get; set; }
    public InventoryDetail InventoryDetail { get; set; }
    public bool Discontinued { get; set; }
    public Category Category { get; set; }
}

You can then do everything you are used to doing with Complex Types. Here’s how I use it in a query:

var outOfStockProducts = from c in context.Products
                         where c.InventoryDetail.UnitsInStock == 0
                         select c;

As you can see, Complex Type support with POCO is really straightforward to use. There are a couple of things you need to keep in mind when using complex types support with POCO:

You must define your Complex Type as a class. Structs are not supported.
You cannot use inheritance with your complex type classes.

While we are on the topic of Complex Types, I thought I’d mention one other thing: Did you know that the Entity Framework designer in Visual Studio 2010 supports complex type declarations?

In Visual Studio 2008, you had to manually add the Complex Type declaration to the CSDL. That is all history with the Complex Type support in the designer in Visual Studio 2010.

And what’s cool is that because Visual Studio 2010 supports Multi-Targeting, you can use this capability when building applications that target .NET Framework 3.5, using Entity Framework 3.5 as well!

Deferred/Lazy Loading

In my sneak preview post on Deferred Loading two weeks ago, I mentioned that there is now Deferred Loading support in Entity Framework. It comes as no surprise then that the default code-generated entity types out of the box based on EntityObject will offer Deferred Loading. If you are wondering whether Deferred Loading is supported with POCO objects, then I think you will be happy to know that you can get Deferred Loading with POCO as well.

There are two things you need to do in order to get Deferred Loading support with POCO entities:

Declare the property that you would like to load lazily as virtual. These properties can be any collection type that implements ICollection<T> or they can be a reference representing a 1/0..1 relationship.

For instance, here’s a part of the updated Category entity class which I have modified to support Deferred Loading:

public class Category
{
    public int CategoryID { get; set; }
    public string CategoryName { get; set; }
    public string Description { get; set; }
    public byte[] Picture { get; set; }
    public virtual List<Product> Products { get; set; }
    ...

2. Enable deferred loading on the context:

context.ContextOptions.DeferredLoadingEnabled = true;

That’s it. You will now get automatic Deferred Loading for your POCO types without having to do anything else.

So how exactly does this work and what’s going on under the covers?

The reason why this works is because when I marked my collection property as virtual, this allowed the Entity Framework to provide a proxy instance for my POCO type at runtime, and it is this proxy that does automatic deferred loading. The proxy instance is based on a type that derives from my own POCO entity class - so all functionality you have provided is preserved. From a developer point of view, this allows you to write persistence ignorant code even when deferred loading might be a requirement.

If you were to inspect the actual instance in the debugger, you will see that the underlying type for the instance is different from the original type that I declared:

While the Entity Framework does its best to provide automatic deferred loading with minimal friction, this is something you need to be aware of when dealing with manual creation of instances that you want to then add or attach, or when you serialize/deserialize instances.

Manual instantiation of Proxy instances for POCO entities

In order to enable creation of proxy instances for adding/attaching, you can use the CreateObject factory method on ObjectContext for creating entity instances:

Category category = context.CreateObject<Category>();

Try to keep this in mind and use CreateObject when creating instances that you want to then use with the Entity Framework.

More Efficient Change Tracking with “Change Tracking Proxies”

The standard POCO entities we have talked about until now rely on snapshot based change tracking – i.e. the Entity Framework will maintain snapshots of before values and relationships of the entities so that they can be compared with current values later during Save. However, this comparison is relatively expensive when compared to the way change tracking works with EntityObject based entities.

There is another type of proxy that will allow you to get better performance out of change tracking with POCO entities.

If you are familiar with IPOCO, you know that IEntityWithChangeTracker was one of the interfaces you were required to implement to provide change notifications to the Entity Framework.

Change Tracking proxies subclass your POCO entity class to provide you with this capability during runtime without requiring you to implement the IPOCO interfaces yourself.

In many ways, you get the best of both worlds with this approach: You get persistence ignorance with POCO classes and you get the performance of EntityObject / IPOCO when it comes to change tracking.

To get change tracking proxies, the basic rule is that your class must be public, non-abstract or non-sealed. Your class must also implement public virtual getters/setters for all properties that are persisted. Finally, you must declare collection based relationship navigation properties as ICollection<T> only. They cannot be a concrete implementation or another interface that derives from ICollection<T> (a difference from the Deferred Loading proxy)

Here’s an example of my POCO class for Product that will give me more efficient proxy based change tracking at runtime:

public class Product
{
    public virtual int ProductID { get; set; }
    public virtual string ProductName { get; set; }
    public virtual int SupplierID { get; set; }
    public virtual string QuantityPerUnit { get; set; }
    public virtual decimal UnitPrice { get; set; }
    public virtual InventoryDetail InventoryDetail { get; set; }
    public virtual bool Discontinued { get; set; }
    public virtual Category Category { get; set; }
}

Once again, keep in mind that you must use CreateObject for creating proxy instances you want to then add or attach to the context. But pure POCO entities that don’t rely on proxies and proxy based entities can work together. You need to only use CreateObject when dealing with proxy based entities.

What if I want both Deferred Loading and better change tracking for the same POCO type?

The two are not mutually exclusive and you don’t have to choose between a Deferred Loading proxy and a Change Tracking proxy. If you want Deferred Loading and efficient change tracking, you just have to follow the rules for Change Tracking via proxies, and enable Deferred Loading. Change Tracking proxies will give you deferred loading if deferred loading is enabled.

Explicit Loading

All this deferred loading capability is great – but there are plenty of you out there that want to be in full control of how you load related entities. You might even choose to go the route of pure POCO without having to resort to any of the automatic proxy generation done for you.

This is a perfectly acceptable (and preferable in many cases) and you can use explicit loading of relationships and be in complete control of how you query for data from the database.

There are two options for doing Explicit Load with POCO:

One is to use ObjectContext.LoadProperty and specify the name of the navigation property you want to load:

context.LoadProperty(beveragesCategory, "Products");

This gets the job done – but it isn’t very type safe as you can see. If I don’t have the right name of the navigation property here, I will get a runtime exception.

Some of you might actually prefer this:

context.LoadProperty(beveragesCategory, c => c.Products);

I can use a lambda expression to specify the property that I want to load explicitly, and this is offers more type safety.

So that’s about everything I planned on covering in the second post. There’s more to come however – in the final part of this series, we’ll go over some of the things to be aware of when dealing with pure POCO (non proxy) instances and keeping things in sync between your object graph and the Object State Manager. We will also cover variations of SaveChanges that you might want to be aware of.

In the meantime, check out the sample code that I have updated to cover some of the things we have talked about in this post.

Faisal Mohamood
Program Manager, Entity Framework

Filed under: ADO.NET, Entity Framework

Attachment(s): NorthwindPocoSamplePart2.zip

Updated Entity Framework Documentation for Beta1

2009-05-31T02:12:25Z

With the release of Visual Studio 2010 Beta 1, we have released supporting Entity Framework documentation. Below are links to documentation for new Entity Framework features and scenarios. Along with feedback on the Entity Framework, we would like to hear your feedback on the documentation. What works for you? What doesn’t? What’s missing? We’ll work to incorporate your feedback in future releases.

Thanks!

Entity Framework User Education Team

Persistence-Ignorant Objects

You can use your own custom data classes together with your data model without making any modifications to the data classes themselves. This means that you can use "plain old" CLR objects (POCO), such as existing domain objects, with your Entity Framework application. For more information, see Persistence Ignorant Objects (Entity Framework).

Deferred Loading of Related Objects

With deferred loading, also known as lazy loading, related objects are automatically loaded from the data source when you access a navigation property. For more information, see Shaping Query Results (Entity Framework).

Functions in LINQ to Entities Queries

The EntityFunctions and SqlFunctions classes provide access to canonical and database functions from LINQ to Entities queries. The EdmFunctionAttribute allows a CLR method to serve as a proxy for a function defined in the conceptual model or storage model. For more information, see Calling Functions in LINQ to Entities Queries.

Customized Object Layer Code Generation

You can configure the ADO.NET Entity Data Model Designer to use text templates to generate customized object layer code. For more information, see How to: Customize Object Layer Code Generation.

Model-First Support

The Create Database Wizard enables you to do conceptual modeling first, and then create a database that supports the model. For more information, see How to: Generate a Database from a Conceptual Model.

Complex Type Support in the Entity Data Model Designer

The ADO.NET Entity Data Model Designer now supports complex types. For more information, see the following topics:

Naming Service

The Entity Data Model Wizard and the Update Model Wizard provide the option of using singular or plural forms of Entity, EntitySet, and NavigationProperty names to make application code more readable. For more information, see Choose Your Database Objects Dialog Box (Entity Data Model Wizard) and Choose Your Database Objects Dialog Box (Update Model Wizard).

Improved Model Browser Functionality

The Model Browser window of the ADO.NET Entity Data Model Designer enables you to delete objects from the storage model and to search the conceptual and storage models for a specified string. For more information, see Model Browser Window and How to: Delete Objects from the Storage Model.

User-Defined Functions (Entity SQL)

Entity SQL supports calling user-defined functions in a query. For more information, see User-Defined Functions (Entity SQL).

Better N-Tier Concurrency Management for the Entity Framework(Sum)

2009-05-30T17:17:07Z

Better N-Tier Concurrency Management for the Entity Framework

Posted in Technical at 11:03 am by Tony

I just wrote an article for MSDN Magazine (due out in December) about developing n-tier applications for both LINQ to SQL and the Entity Framework. While researching the topic, I noticed a certain awkwardness with the Entity Framework API when it came to managing concurrency with a timestamp fields, as compared with LINQ to SQL. L2S has an overloaded Attach method that accepts a bool asModified parameter indicating the presence of a timestamp field used for concurrency. The Entity Framework, on the other hand, requires attaching the original unmodified entity, then calling ApplyAllChanges, passing in the modified entity. This doesn’t make a whole lot of sense when using a timestamp for concurrency checking, because the only original value you care about is the timestamp, which is passed in unchanged as part of the modified entity. Using timestamps is a great idea because it relieves the client from needing to cache the object’s original values and reduces the amount of data sent over the wire when you’re sending entities to a service for persistence. In the article, I got around this by querying the database from the service using the key value of the modified entity. Yuck!

Before you throw up your hands in despair, I have good news for you. Danny Simmons, a developer and program manager on the EF team, just came up with a couple extension methods to obviate the need for original entity values. Rather than taking the original entity and applying property changes from a detached object that has been modified, you can simply take the detached object and set the state of each property to modified. What you’re essentially saying is, “Look, I already have a modified entity, just change the state of each property from ‘Unchanged’ to ‘Modified’ so that when I call SaveChanges the updates are persisted.”

There’s one more wrinkle to this scenario: using Data Transfer Objects (DTOs) instead of EF entities in the Data Access Layer (DAL). Although v.2 of the Entity Framework will allow you to use DTOs directly as EF entities, this is not yet fully supported in v.1, meaning that an UpdateOrder method would accept a DTO.Order object, which you would use to create an L2E.Order object. To accomplish this, I created an extension method for ObjectContext called CreateEntityFromObject which accepts a DTO and uses reflection to copy properties from the DTO to the Entity and create an EntityKey. The code to persist changes to an Order entity now looks like this:

static DTO.Order UpdateOrder(DTO.Order order)

{

using (NorthwindEntities db = new NorthwindEntities())

{

// Create new order entity from DTO.Order

Order updatedOrder = db.CreateEntityFromObject

<Order>("OrderSet", order);

// Attach modified order (with original timestamp)

db.AttachAsModified(updatedOrder);

try

{

db.SaveChanges();

}

catch (OptimisticConcurrencyException conflictEx)

{

Console.WriteLine(conflictEx.Message);

return null;

}

return GetOrder(order.OrderID);

}

Here is the CreateEntityFromObject extension method:

public static TEntity CreateEntityFromObject<TEntity>

(this ObjectContext context,

string entitySetName, object dto)

where TEntity : IEntityWithKey, new()

{

// Create a new entity

TEntity entity = new TEntity();

// Copy properties

foreach (PropertyInfo dtoProp in dto.GetType().GetProperties())

{

PropertyInfo entityProp = typeof(TEntity).GetProperty(dtoProp.Name);

object propValue = dtoProp.GetValue(dto, null);

entityProp.SetValue(entity, propValue, null);

}

// Set the entity key

entity.EntityKey = context.CreateEntityKey(entitySetName, entity);

// Return the entity

return entity;

}

To see all of this in action, you can download the code for my sample concurrency application. Enjoy!

12.11.08

Bug in EF v.1 Limits N-Tier Scenarios

Posted in Technical at 8:02 am by Tony

About a month ago I wrote a blog post on an extension method for the Entity Framework called AttachAsModified, which was offered by Danny Simmons shortly after PDC as a way to perform disconnected updates from an n-tier service. Unfortunately, I discovered what I consider to be a bug in EF v.1 that limits your ability to use the AttachAsModified extension method. The problem surfaces when the entity you’re trying to update has reference properties to related entities. For example, say you have an Order entity with a Customer navigation property that relates it to the Customer entity. If Order contained a CustomerID property representing the foreign key, you could simply set its value. But the EF models this as an association between Order and Customer and does not include CustomerID as a foreign key in the Order entity. (The EF team, nevertheless, is considering allowing foreign keys into the model.)

The way to set reference properties in EF is to set the EntityKey of the reference property to a new key based on the foreign key value you want to set it to. For example, if you want to change the Customer that an Order is associated with, you need to do the following:

updatedOrder.CustomerReference.EntityKey =

new EntityKey("NorthwindEntities.CustomerSet",

"CustomerID", newCustomerID);

The problem is that, when you call SaveChanges on the ObjectContext, EF includes the non-reference Customer property in the WHERE clause of the UPDATE statement.

exec sp_executesql

N'update [dbo].[Orders]

set [CustomerID] = @0,

[OrderDate] = @1,

-- other fields set to null

where (([CustomerID] is null and ([OrderID] = @2))

and ([RowVersion] = @3))

N'@0 nchar(5),@1 datetime,@2 int,@3 binary(8)',

@0=N'ANATR',@1='1996-09-29 00:00:00:000',@2=10308,@3=0x000000000004BF3D

If you leave it null, or set it to anything other than the original value, this will result in an OptimisticConcurrencyException. This means you are required to pass in the Order’s original CustomerID value, which doesn’t make sense if you are using a timestamp column to manage concurrency (which is the purpose of the [RowVersion] in the above WHERE clause.

For this reason, I can’t bring myself to require the client app to retain original foreign key values, and I’m left having to re-query the database for the original entity, then set the timestamp property to that passed in with the updated entity. After detaching the entity to commit this change and mark it as ‘unmodified’, you can then modify the original entity properties to the values of the updated entity and call SaveChanges. While re-querying the database for the original entity isn’t pretty (and quite inefficient), I think it’s a better alternative to passing in the original values from the client (an approach advocated by MS architect Cesar de la Torre), because it won’t require code changes in the client when the EF team fixes the bug (hopefully before the release of v. 2!).

Here is a sample app that demonstrates the bug and also how to avoid it by re-querying the database. Cheers.

Updating data using Entity Framework in N-Tier and N-Layer Applications (short lived EF contexts) - (Part 1)

First of all, we are talking about using Entity Framework and how it fits within N-Tier and N-Layer applications, ok?, that’s our initial scenario.

An N-Tier application is an application where you have 3 or more physical tiers. I mean with that things like, “Presentation/Client Tier”, “Application/Business Server Tier” and “Data Tier” (a database server in most of the cases) and nowadays we use web services (or even better, WCF Services) to communicate between presentation tier and the application server tier. Here you see a simple & typical picture about N-Tier architecture:

As you can see, all the client applications (we could be for instance WinForms, WPF, or even Silverlight apps) need to remotely access to the application Server tier using for example WCF Services.

Also, in my opinion. RIA (Rich Internet Applications) is a special subset of N-Tier apps.

A different matter is that we’d probably design our application as an N-Layer application, I mean, with several logic layers where we implement different logic tasks. For example we could have the DAL layer (Data Access Layer), BLL Layer (Business Logic Layer), BFLL Layer (Busines Façade Logic Layer), WCF Service Layer and several Presentation layers depending of the pattern we use, like MVC (Model-View-Controller), MVP (Model-View-Presenter), etc.. Also, within the N-Layer architecture, you can guess that Entity Framework fits as the DAL Layer (Data Access Classes) as well as using EF entities as our disconnected entities to pass thru all the layers, all right?

BTW, not all N-Layer apps should be N-Tier apps, but all N-Tier Apps must internally be designed as N-Layer. I mean, there are many cases where the less you physically split your model, the better for performance (more tiers is good for scalability but not for pure performance, due to latencies). Remember, N-Layer is about logic layers.

OK!, so if we get back to the N-Tier architecture (physical tiers), like I said, we need remote mechanisms to communicate the client tier with the application server tier (for instance, WCF Services) and therefore when we query the database from the app server tier, to obtain data (like an Order), we keep it as an EF entity, then we disconnect it from the EF context (detach), WCF serializes it and sends that disconnected entity to the presentation tier (client apps & machines).

So, most enterprise applications use an architectural pattern that needs a stateless facade for its business logic (like N-Tier & N-Layer apps). They have scenarios like WebServices or WCF, ASP.NET applications, Traditional Desktop Application (Windows Forms, WPF) consuming WCF Services, etc. in those cases data access works “disconnected oriented”, I mean, database data (in the real tables) are not blocked while the user is working in the client tier (btw, this is better for scalability). So, in the client/presentation tier, the user will be working and maybe, he changes that entity’s data (which is disconnected from the server) and after a while (at any time) the user submits that data to the application server and then the DAL layer (Entity Framework and LINQ to EF, in our case) will update that data into the database. Right?. Well, if we just do that, it will be just a “Last-In-Wins” or what I call, a “Too Optimistic Update” ;-) . Well, in many apps which are not very exigent or complex regarding updates, this can be enough, but then, we could have other apps where the users need to know if data (regarding the same entity and records he is using at client tier) has changed in the database while he was working and before he tried to update the data. In that case we should use “Optimistic Concurrency Updates” managing “Optimistic Concurrency Exceptions”.

So, I am using all the following stuff:

- Entity Framework and LINQ to Entities as our DAL Layer

- WCF as our remote communication technology

- Any .NET UI technology as our client App (WPF, WinForms, OBA or even Silverlight)

Simple way: Updating data in N-Tier applications and using Entity Framework with detached entities

In order to understand what I mean, first of all, I am going to explain how to implement just simple updates in N-Tier applications and using Entity Framework. So this case is the one I called “Last-In-Wins” or a “Too Optimistic Update” ;-). So in this first case I won’t manage any Optimistic Concurrency Exception.

First of all, we’d have a business class (BLL class) which would be using EF & LINQ to Entities so that class would be querying the database; let’s say to get a Customer data and to return that entity’s data to the client/presentation tier (thru a WCF Service). The BLL class code could be something like the following code:

public class CustomerBll

{

private MyDataBaseEntities context;

public CustomerBll()

{

context = new MyDataBaseEntities();

}

public Customer GetCustomer(string customerID)

{

var q = from c in context.Customers //.Include("Orders")

where c.CustomerID == numCustomerID

select c;

var customer = q.First();

context.Detach(customer);

return customer;

}

Ok, if you know LINQ to entities, this is a very simple method, right?. The important thing to take into account is the following: “we are returning a disconnected/detached entity data object” passing it to the upper layers (Service layeràPresentation Layers). It means that regarding Entity Framework we’ll be working with ObjectContext objects in a “short lived context” way. Basically, when we’ll close the loop, we’ll need to re-attach modified EntityObjects, that were updated outside of an ObjectContext (in detached state). This is a very common scenario when we're using stateless facades (most N-Tier & N-Layer apps).

Coming back to our code, then we could have a WCF Service serializing & returning the disconnected/detached entity.

Here you could see the Service contract for the method:

//WCF Contract

[OperationContract]

Customer CustomerBll_GetCustomer(string customerID);

...

//And now, the method’s implementation in the WCF class library:

public Customer CustomerBll_GetCustomer(string customerID)

{

return new CustomerBll().GetCustomer(customerID);

}

Ok, after that, the client app would be consuming the WCF Service and will display the entity’s data (customer’s data) let’s say in a WPF form. Remember that right now, the client app is working with a disconnected/detached entity object and there is not an ObjectStateManager tracking changes. We’ll see how it affects later on…

So, once the data is visible within a form, the user can start changing some data in that form until he decides to actually update that data into the application (for me, it means he wants to update that data into the database), pressing, for instance a big button which says “Update”. J
Right, in this very moment the client application would be calling another WCF Service method called something like UpdateCustomer(), like you see down below:

public void CustomerBll_UpdateCustomer(Customer customer)

{

new CustomerBll().UpdateCustomer(customer);

}

Then, that WCF method is calling the real business logic method, and this is where I am going to show you how to use Entity Framework to update the detached/disconnected but modified entity which is coming back from the client tier. This is the code (remember this is the simple case, I am not managing optimistic concurrency exceptions here):

public void UpdateCustomer(Customer customer)

{

//(CDLTLL) Entity must first be reunited with a Context

//Note I do it with my custom extensor method for disconected environments (N-Tier, etc.)

context.AttachUpdated(customer); //Custom extensor method

context.SaveChanges();

}

Ok, first, in order for the context to be able to update anything (the entity) into the database using SaveChanges(), it has first to have it attached to the context. So, context.SaveChanges() is an EF regular method we always gotta use to update data (changes). But if we’d just use the method context.Attach(customer) before that, it won’t work because that customer entity is new for the context (it was originally detached, serialized and sent to the client tier) and now the context does not know nothing about it, the context “thinks” it is a new entity object and it would not know any changes to update using the context.SaveChanges().

The following is wrong code:

public void UpdateCustomer(Customer customer) //WRONG CODE

{

//(CDLTLL) Entity must first be reunited with a Context

context.Attach (customer); //Custom extensor method

context.SaveChanges();//In this case, nothing happens here…

}

So in this simpler case, when you’d call SaveChanges() nothing would happen.

That is why I created a custom EF extensor method called “context.AttachUpdated()”. To be able to attach updated entities which are disconnected and coming from the client Tier.

It is the following code:

public static void AttachUpdated(this ObjectContext context, EntityObject objectDetached)

{

if (objectDetached.EntityState == EntityState.Detached)

{

object currentEntityInDb = null;

if (context.TryGetObjectByKey(objectDetached.EntityKey, out currentEntityInDb))

{

context.ApplyPropertyChanges(objectDetached.EntityKey.EntitySetName, objectDetached);

//(CDLTLL)Apply property changes to all referenced entities in context

context.ApplyReferencePropertyChanges((IEntityWithRelationships)objectDetached,

(IEntityWithRelationships)currentEntityInDb); //Custom extensor method

}

else

{

throw new ObjectNotFoundException();

}

So, first of all we need to know what is new in this entity, I mean, what are the changes compared with the data we actually have in the database. In order to do that we’d need to query the database and get the actual data using the “context.TryGetObjectByKey()” method and attach it as the original data for that entity within the context.

Then, we can call the “context.ApplyPropertyChanges()” providing our new updated entity. What EF does is that it compares the original data (actual data in the database) with our new/updated entity and then it updates within the context all the property changes just regarding our specific entity (Customer, in this case). After that, when we call to “context.SaveChanges()” in the main method, EF will detect what are actually those changes and it will be able to update it into the real database (SQL Server, for instance).

Notice that after calling to “context.ApplyPropertyChanges()” I am calling another method called “ApplyReferencePropertyChanges()”. This other method is actually another extensor method which applies all my entity property changes but into all the referenced entities within our EF model (Customer could be related to Company, Order, etc.). This is an important method, otherwise we’ll be taking into account just our isolated entity (Customer). Here you can see my “context.ApplyReferencePropertyChanges()” custom context extensor method:

public static void ApplyReferencePropertyChanges(this ObjectContext context,

IEntityWithRelationships newEntity,

IEntityWithRelationships oldEntity)

{

foreach (var relatedEnd in oldEntity.RelationshipManager.GetAllRelatedEnds())

{

var oldRef = relatedEnd as EntityReference;

if (oldRef != null)

{

// this related end is a reference not a collection

var newRef = newEntity.RelationshipManager.GetRelatedEnd(oldRef.RelationshipName, oldRef.TargetRoleName) as EntityReference;

oldRef.EntityKey = newRef.EntityKey;

}

So with that, we’re done!, it works ok following the method I said “Last In Wins” or a “Too Optimistic Update” ;-)

Btw, another option (it works almost the same) would be not to query the database to know the actual data (kind of original data for the context) with “context.TryGetObjectByKey()” but to say to the context that all the properties within my entity have actually changed, “just because I say it”. After that, when we call “context.SaveChanges()” it will update all the entity properties just because we said that!. J

Here you can see this other entity extensor method (In this case I coded as an entity extensor method instead as a context extensor method, ok?):

public static void SetAllModified<T>(this T entity, ObjectContext context) where T : IEntityWithKey

{

var stateEntry = context.ObjectStateManager.GetObjectStateEntry(entity.EntityKey);

var propertyNameList = stateEntry.CurrentValues.DataRecordInfo.FieldMetadata.Select(pn => pn.FieldType.Name);

foreach (var propName in propertyNameList)

{

stateEntry.SetModifiedProperty(propName);

}

In this other case (using SetAllModified()) our code within "UpdateCustomer()" would be somethin like:

public void UpdateCustomer(Customer customer)
{
context.Attach(customer);
customer.SetAllModified(context); // custom extension method
context.SaveChanges();
}

Cool!, this seems all great, we are happy and we are living in a wonderful world. Sure?. Well, it depends, but like I said at the beginning of this post, this code we have written does not cover scenarios where we want to manage “Optimistic Concurrency Updates & Exceptions”, I mean, let’s say any other guy changed some data, regarding that same data customer, during the timeframe after I performed my Customer query but before I actually updated it to the database. I mean, someone changed data in the database just before I called to context.AttachUpdated(customer) and context.SaveChanges(). Ok, then, the initial original user won’t be aware that he might be over writing that new data that the other second user updated… In many cases this can be dangerous depending on the application’s type.

Well, I guess this post is getting too long, I’ll write a second post (very soon) explaining “How to: Update data in N-Tier applications and using Entity Framework with detached entities and managing Optimistic Concurrency Updates and Exceptions”.

Optimistic Concurrency Updates using Entity Framework in N-Tier and N-Layer Applications (Part 2)

This is my second post about "Updating data using Entity Framework in N-Tier and N-Layer Applications". If you wanna read the basics, go to my first post here:

http://blogs.msdn.com/cesardelatorre/archive/2008/09/04/updating-data-using-entity-framework-in-n-tier-and-n-layer-applications-short-lived-ef-contexts.aspx

So!, I finished my first post saying that the code I showed does not cover scenarios where we want to manage “Optimistic Concurrency Updates & Exceptions”, I mean, let’s say any other guy changed some data, regarding that same data customer, during the timeframe after I performed my Customer query but before I actually updated it to the database. I mean, someone changed data in the database just before I called to context.AttachUpdated(customer) and context.SaveChanges(). Ok, then, the initial original user won’t be aware that he might be over writing that new data that the other second user updated… In many cases this can be dangerous depending on the application’s type.

The goal is: “How to Update data in N-Tier and N-Layer applications using Entity Framework with detached entities and managing Optimistic Concurrency Updates and Exceptions”.

I think this is a great subject and the way you gotta do it is not very clear in official documentation neither in most of the Entity Framework books and articles (at least, at this time..).

Cool! :-) let’s see how we can achieve this new scenario!.

Fisrt of all, the Entity Framework can enforce optimistic concurrency when generating the update and delete SQL sentence. It does this by including original values in the WHERE clause for any entity property with the ConcurrencyMode attribute value set to Fixed. But by default, if you just create an EF model, entity fields are not set as concurrency fields.

Ok, so first thing would be to change that attribute to any entity field!. and which field do we use?, well, you can use whichever you like (Name, IDs, etc.) and you even can set several fields to have ConcurrencyMode attribute value set to Fixed.

Here you can see how to change the EDM in VS.2008:

If you change this "Customer" entity editing the EDM, you could see how the SQL sentence update is modified adding that column in the WHERE clause for any Update or Delete Commands:

exec sp_executesql N'update [SalesLT].[Customer]

set [FirstName] = @0

where (([CustomerID] = @1) and ([FirstName] = @2))

',N'@0 nvarchar(17),@1 int,@2 nvarchar(14)',@0=N'Cesar App Changed',@1=29485,@2=N'Cesar Original Value'

In this case I'm using the "FirstName" field (even several fields), but, what I usually use is a TimeStamp field added to each table and entity. In that way I always can check in the same way (same field) if the record has changed.

Then, an OptimisticConcurrencyException is raised if the original row is not found.

Here you can see that exception being raised when I modified the customer's name in the database just before updating from the application using Entity Framework:

"Store update, insert, or delete statement affected an unexpected number of rows (0). Entities may have been modified or deleted since entities were loaded. Refresh ObjectStateManager entries."

Cool!, this is great, so when we get this exception we can decide if we want the user to know it, refresh de form and maybe start again, or we could show the differences, or we could even just catch the exception, log the problem in a trace and just save the last operation. Ok!, but think!, what is wrong when we are using detached entities?. Sure! you got it!, the problem is that in order for the EF context to to know the original values, you'd need to use the same context since the very moment we started quering the database, updating, and so on. But, remember we are in a scenario (N-Tier and N-Layered apps) where EF contexts have a short life because we use stateless server objects and we detach the EF entity objects, and when we attach again the updated entity, we do it on a completely new context!, that new context knows nothing about the original query and the original values!! (if you wanna see more about this, just read my first post).

For instance, if we just set the concurrency mode to FIXED to any field and we use the code I showed in my first post about EF and data updates in N-Tier apps, it won't work!. Why?, because when the business class is getting the updated data entity back, the context does not know the real original values, and if we use the first method I explained in my first post (using the AttachUpdated() custom extensor method and the context.TryGetObjectByKey()), the WHERE clause is going to compare it with current database values (which are not the real original values). Or if we use the second method I showed (using just the SetAllModified()), it is even worse, in this case it does not even know anything about the current database values and it is going to place in the WHERE clause exactly the same value we want to update, so in this second case, it will always throw an exception!!!.

So, what do we need in order to make this to work?, of course, we'd need to "artificially" re-construct the context like if we had the same context!, I mean, we need to keep somewhere the original values we got the first time we queried the database, and attach it to the second short lived context, right before we attach the updated entity. In this case, it works like a charm!. :-)

Let's see the code. Regarding the query business methods and WCF Service when we are just querying, we don't need to change anything, we return data to the client tier in the same manner. But then, when we get the data in the client tier (let's say in a WPF, Silverlight or WinForms app) we need to keep that data in a safe place. I mean, we need to clone the entity data so after the user has changed the data fields in the form and presses the Save button, we'll actually send the updated data entity plus the original values, so the server components will be able to re-create a context who will know how to handle optimistic concurrency.

But, before getting deep into the server "update methods", I wanna notice another problem. Entity Framework actually lacks of a "Clone()" entity method. First option (a really bad one) would be querying twice to the server WCF services so we get two data entities. But this approach is ugly because we loose performance and also there is a small possibility that while we query again, the data in the database has chaged. So, no way!, we need to clone our detached entity in the client side!

OK, for that, I'm using my own custom method (as a utility method in the client layers) which is based on memory streams copies:

//(CDLTLL)
//Cloner by memory - Short code
public static T CloneSerializing<T>(this T entityObject) where T : EntityObject, new()
{
 DataContractSerializer datContractSer = new DataContractSerializer(entityObject.GetType());
 MemoryStream memoryStream = new MemoryStream();
 datContractSer.WriteObject(memoryStream, entityObject);
 memoryStream.Position = 0;
 T clonedObject = (T)datContractSer.ReadObject(memoryStream);
 return clonedObject;
}

You could find faster ways to clone EF detached entites, but the thing I like about this is that it is based just on a few lines of code.

For instance, Matthieu MEZIL has made an entity cloner based on Reflection:
http://msmvps.com/blogs/matthieu/archive/2008/05/31/entity-cloner.aspx

Take a look. It could be faster (I have not compared it), but it is a lot of code..., well, you can choose. :-)

Then, we get to the fun stuff, let's see how we handle the server code regarding updates and optimistic concurrency.

First of all, we need a slightly different WCF Service method, because we need to get two entities (original values and updated values):

public void CustomerBll_UpdateCustomerEx(Customer newCustomer, Customer originalCustomer)
{
new CustomerBll().UpdateCustomerOptimisticConcurrency(newCustomer, originalCustomer);
}

And then, our business class method, the "core" of this post!! :-)

public void UpdateCustomerOptimisticConcurrency(Customer detachedCustomer, Customer originalCustomer)
{
    try
    {
        //(CDLTLL) Original entity must first be reunited with a Context
context.Attach(originalCustomer);

//(CDLTLL)Apply property changes to all referenced entities in context
context.ApplyReferencePropertyChanges(detachedCustomer, originalCustomer);

        // Apply entity properties changes to the context
context.ApplyPropertyChanges(detachedCustomer.EntityKey.EntitySetName, //"Customers",
                                                           detachedCustomer);
        //(CDLTLL) EF SaveChanges() persists all updates to the store and
        // resets change tracking in the object context.
context.SaveChanges();
    }
    catch (OptimisticConcurrencyException e)
    {
        //(CDLTLL) Concurrency Exception Management
        //context.Refresh(RefreshMode.ClientWins, newCustomer); // Last in wins
        //myLogger.Write(e);
        //context.SaveChanges();
        //Manage or throw the exception

throw (e);

}
}

Here we first tell to the context what were the original values in the database when we first queried, then it is when we tell to the context about our updated data and we actually do it not just regarding our entity, we also apply changes to all referenced entities within our EF graph (using our custom extensor method called context.ApplyReferencePropertyChanges) so when we finally call to "context.SaveChanges()", the EF will smoothly handle the "Optimistic Concurrency Updates and/or its Exception"!, it will actually look for original values set in the WHERE clause of our Update/Delete final sentence. Cool!. :-)

FINAL THOUGHTS

It would be nice to have a way to actually hide the original values (hidden cloned entity) within the regular detached entity object. Doing so, it would be transparent for the developer who is working on the client layers...

You can also take a look to ENTITYBAG (by Danny Simmons). I'm not using it at all in the code I've been talking about.

Perseus: Entity Framework EntityBag

http://code.msdn.microsoft.com/entitybag/

EntityBag – Wrap-up and Future Directions

http://blogs.msdn.com/dsimmons/archive/2008/01/28/entitybag-wrap-up-and-future-directions.aspx

EntityBag Part II – Modes and Constructor

http://blogs.msdn.com/dsimmons/archive/2008/01/20/entitybag-part-ii-modes-and-constructor.aspx

EntityBag Modes with the Entity Framework (John Papa)

http://nypapa.com/all/entitybag-modes-with-the-entity-framework/

Coming to the Entity Framework: A Serializable EntityBag for n-Tier Deployment

http://oakleafblog.blogspot.com/2008/01/coming-to-entity-framework-serializable.html

The EntityBag concept is actually quite neat and it solves many points I talked about, but it has also several restrictions:

First of all, there’s the fact that it requires us to run .Net and the EF on the client, and it also requires that the code for your object model has to be available on the client, so, you loose the great discover and interoperability we have with basic Web Services (or advanced WCF wsHttp or basicHttp services, etc.), so I guess ENTITYBAG is not interoperable with Java or any non .NET language.

Examples

The example in this topic is based on the Adventure Works Sales Model. In this example, an updated SalesOrderDetail object is passed to the UpdateItemChanges method, together with the original object. This enables changes to be applied without querying for the object or having to persist it in memory.

private static void ApplyItemUpdates(SalesOrderDetail originalItem,

    SalesOrderDetail updatedItem)

    using (AdventureWorksEntities advWorksContext =

        new AdventureWorksEntities())

try

            // Attach the original item to the object context.

            advWorksContext.Attach(originalItem);

            // Call the ApplyPropertyChanges method to apply changes

            // from the updated item to the original version.

            advWorksContext.ApplyPropertyChanges("SalesOrderDetail",

                updatedItem);

            advWorksContext.SaveChanges();

        catch (InvalidOperationException ex)

            Console.WriteLine(ex.ToString());

In this example, the original SalesOrderDetail object is retrieved and then changes are applied to it based on an updated SalesOrderDetail object that is passed to the UpdateItemChanges method.

private static void ApplyItemUpdates(SalesOrderDetail updatedItem)

    // Define an ObjectStateEntry and EntityKey for the current object.

    EntityKey key;

    object originalItem;

    using (AdventureWorksEntities advWorksContext =

        new AdventureWorksEntities())

try

            // Create the detached object's entity key.

            key = advWorksContext.CreateEntityKey("SalesOrderDetail", updatedItem);

            // Get the original item based on the entity key from the context

            // or from the database.

            if (advWorksContext.TryGetObjectByKey(key, out originalItem))

                // Call the ApplyPropertyChanges method to apply changes

                // from the updated item to the original version.

                advWorksContext.ApplyPropertyChanges(

                    key.EntitySetName, updatedItem);

            advWorksContext.SaveChanges();

        catch (InvalidOperationException ex)

            Console.WriteLine(ex.ToString());

Here's one approach to updating a reference in an entity in the mid tier of a SOA app.

public static EnduranceActivity UpdateEnduranceActivity(EnduranceActivity currentActivity, EnduranceActivity originalActivity, Route newRoute)

{

using (FitnessAppContainer appContainer = new FitnessAppContainer(ConnectionString))

{

if (null != newRoute)

{

originalActivity.Route = newRoute;

}

appContainer.Attach(originalActivity);

appContainer.ApplyPropertyChanges("FitnessAppContainer.EnduranceActivitySet", currentActivity);

appContainer.SaveChanges();

}

return originalActivity;

}

We are looking at adding an option to ApplyPropertyChanges that will update references as well for V2 as well as other features that will make this easier.

· Here's a more generic approach based on a related post by Danny Simmons. I have confirmed that this works:

Code Snippet

public static EnduranceActivity UpdateEnduranceActivity(EnduranceActivity currentActivity, EnduranceActivity originalActivity, Route newRoute)

{

using (FitnessAppContainer appContainer = new FitnessAppContainer(ConnectionString))

{

appContainer.Attach(originalActivity);

ApplyReferencePropertyChanges(

(IEntityWithRelationships)currentActivity,

(IEntityWithRelationships)originalActivity);

appContainer.ApplyPropertyChanges(

"FitnessAppContainer.EnduranceActivitySet",

currentActivity);

appContainer.SaveChanges();

}

return originalActivity;

}

public static void ApplyReferencePropertyChanges(

IEntityWithRelationships oldEntity,

IEntityWithRelationships newEntity)

{

foreach (var relatedEnd in oldEntity.RelationshipManager.GetAllRelatedEnds())

{

var oldRef = relatedEnd as EntityReference;

if (oldRef != null)

{

// this related end is a reference not a collection

var newRef = newEntity.RelationshipManager

.GetRelatedEnd(oldRef.RelationshipName, oldRef.TargetRoleName)

as EntityReference;

oldRef.EntityKey = newRef.EntityKey;

}

· Hi,

I have used this method as part of a generic graph update method for my wcf services. However, it appears to ignore the reference values entirely. I can see that the reference properties are set in the method but when savechanges is called they do not persist?

When i test out workign with an always connected object graph (no wcf) the method works fine and the changes persist, any ideas?

On a side note, i've resorted to using dependency injection to have specific classes responsible for managing the updating of objects from wcf services as reflection was getting way too messy. I have the concept of allowing an udpate strategy key to be passed into the web service to instruct how the graph should be updated, with sensible defaults of course (association depth of 1 for example).

public void Update<T>(T entity, string updateStrategyKey)

{

EntityObject updatedEntity = entity as EntityObject;

// we're only interested in detached entities, any others will be updated by SaveChanges anyway

if (updatedEntity == null || updatedEntity.EntityState != EntityState.Detached)

return;

// get the current (old) entity from the object state manager using the updated entity

EntityObject oldEntity = GetObjectByKey(updatedEntity) as EntityObject;

// get context and relationship info about old and updated

ObjectContext objectContext = this.ObjectContext;

Type updatedEntityType = updatedEntity.GetType();

Type updatedEntityBaseType = GetBaseType(updatedEntityType);

// apply reference property changes (not handled by context's ApplyPropertyChanges)

ApplyReferencePropertyChanges(oldEntity, updatedEntity);

// apply scalar property changes

objectContext.ApplyPropertyChanges(updatedEntityBaseType.Name.ToString(), updatedEntity);

// if an update strategy is in place, use a dependency injected service to implement if available

if (!String.IsNullOrEmpty(updateStrategyKey) && updateStrategyKey != UpdateStrategyKey.RootOnly.ToString())

{

string repositoryGraphUpdaterServiceID = updatedEntityType.ToString() + "GraphUpdater";

IRepositoryGraphUpdater repositoryGraphUpdater = ServiceLocator.TryResolve<IRepositoryGraphUpdater>(repositoryGraphUpdaterServiceID);

if (repositoryGraphUpdater != null)

{

repositoryGraphUpdater.Update(updatedEntity, updateStrategyKey);

}

// apply reference property changes (not handled by context's ApplyPropertyChanges)

private void ApplyReferencePropertyChanges(IEntityWithRelationships oldEntity, IEntityWithRelationships updatedEntity)

{

foreach (var relatedEnd in oldEntity.RelationshipManager.GetAllRelatedEnds())

{

var oldRef = relatedEnd as EntityReference;

if (oldRef != null)

{

// this related end is a reference not a collection

var newRef = updatedEntity.RelationshipManager.GetRelatedEnd(oldRef.RelationshipName, oldRef.TargetRoleName)

as EntityReference;

oldRef.EntityKey = newRef.EntityKey;

}

· I've just been debugging this and it's the line in red below that doesn't appear to work. What happens for me is that the attached and detached entity keys appear from the old entity (attached) and the updated entity (yet to be attached) is ignored.

This is causing major problems for us as we can not seem to update any entity references as a result (as attach and attachto are not viaable options when protecting updates).

Let's say we have oldEntity below passed in as a customer with a null party reference as follows Customer.Party. The updatedEntity is a detached Customer with an updated party reference.

The problem then seems to be that we cannot use a detached updatedEntity when the oldEntity is attached and the reference you want to update on the attached entity is null, is this correct?

// apply reference property changes (not handled by context's ApplyPropertyChanges) oldentiy is attached and updatedentity not

private void ApplyReferencePropertyChanges(IEntityWithRelationships oldEntity, IEntityWithRelationships updatedEntity)

{

foreach (var relatedEnd in oldEntity.RelationshipManager.GetAllRelatedEnds())

{

var oldRef = relatedEnd as EntityReference;

if (oldRef != null)

{

// this related end is a reference not a collection

var newRef = updatedEntity.RelationshipManager.GetRelatedEnd(oldRef.RelationshipName, oldRef.TargetRoleName)

as EntityReference;

oldRef.EntityKey = newRef.EntityKey;

}

· aha!

I've just discovered that one must set the REFERENCE value on the client for many to ones. I assumed (wrongly) that you could set the property itself and that EF would set the reference on the way back!

It's not very intuitive however to have the following code, any ideas why this gets generated and not just PartyReference like on the entity class itself?

// update the customer's party

Party party = client.GetParty(7);

EntityReferenceOfPartyXwpgZWOi partyRef = new EntityReferenceOfPartyXwpgZWOi();

partyRef.EntityKey = party.EntityKey;

customer.PartyReference = partyRef;

I've finally gotten this working after days of struggle.

I've got a simple database of People and Departments:

I can use strongly-typed ASP.NET MVC views for reference/navigation properties! See the list of departments...

Part of my Person/Edit view:

<% using (Html.BeginForm()) {%>
<%= Html.Hidden("Id", Model.Id) %>
<fieldset>
<legend>Fields</legend>

<label for="Name">Name:</label>
<%= Html.TextBox("Name", Model.Name) %>


<label for="DepartmentId">Department:</label>
<%= Html.DropDownList("DepartmentId", new SelectList((IEnumerable)ViewData["Departments"], "Id", "Name"))%>


<input type="submit" value="Save" />

</fieldset>
<% } %>

Part of my Person controller:

//
// GET: /Person/Edit/5
public ActionResult Edit(Guid id)
{
ViewData["Departments"] = ctx.Department;
Person model = (from Person p in ctx.Person
where p.Id == id
select p).FirstOrDefault();
return View(model);
}
//
// POST: /Person/Edit
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Edit(Person model)
{
ctx.AttachUpdated(model); //extension
ctx.SaveChanges();
return RedirectToAction("Index");
}

To get this working, I extended the Person EntityObject with a new DepartmentId property.

using System;
using System.Data;
using System.Data.Objects.DataClasses;
namespace ProjectName.Models
{
public partial class Person : EntityObject
{
public Guid DepartmentId
{
get
{
try
{
return (Guid)this.DepartmentReference.EntityKey.EntityKeyValues[0].Value;
}
catch
{
return Guid.Empty;
}
}
set
{
this.DepartmentReference.EntityKey = new EntityKey("JunkEntities.Department", "Id", value);
}
}
}
}

And I extended the Entity Framework ObjectContext with new AttachUpdated and ApplyReferencePropertyChanges methods:

using System;
using System.Data;
using System.Data.Objects;
using System.Data.Objects.DataClasses;
public static class EntityFrameworkExtensionMethods
{
public static void AttachUpdated(this ObjectContext ctx, EntityObject objectDetached)
{
if (objectDetached.EntityKey == null)
{
String entitySetName = ctx.DefaultContainerName + "." + objectDetached.GetType().Name;
Guid objectId = (Guid)objectDetached.GetType().GetProperty("Id").GetValue(objectDetached, null);
objectDetached.EntityKey = new System.Data.EntityKey(entitySetName, "Id", objectId);
}
if (objectDetached.EntityState == EntityState.Detached)
{
object currentEntityInDb = null;
if (ctx.TryGetObjectByKey(objectDetached.EntityKey, out currentEntityInDb))
{
ctx.ApplyPropertyChanges(objectDetached.EntityKey.EntitySetName, objectDetached);
ctx.ApplyReferencePropertyChanges((IEntityWithRelationships)objectDetached,
(IEntityWithRelationships)currentEntityInDb); //extension
}
else
{
throw new ObjectNotFoundException();
}
}
}
public static void ApplyReferencePropertyChanges(this ObjectContext ctx, IEntityWithRelationships newEntity, IEntityWithRelationships oldEntity)
{
foreach (var relatedEnd in oldEntity.RelationshipManager.GetAllRelatedEnds())
{
var oldRef = relatedEnd as EntityReference;
if (oldRef != null)
{
var newRef = newEntity.RelationshipManager.GetRelatedEnd(oldRef.RelationshipName, oldRef.TargetRoleName) as EntityReference;
oldRef.EntityKey = newRef.EntityKey;
}
}
}
}

I just wanted to document my progress here. Please suggest improvements.

使用 LINQ To SQL 和Entity Framework实现灵活的数据访问

2009-05-30T17:12:40Z

Microsoft 已面向开发人员发布了两种旨在减少关系数据领域和面向对象的编程之间的阻抗失谐的产品：LINQ to SQL 和 ADO.NET Entity Framework。借助其中任何一种产品，您不必编写大部分探测代码，即可实现对象持久性。

　　本文使用以下技术：

LINQ to SQL、ADO.NET Entity Framework和 SOA

　　迄今为止，Microsoft 已面向开发人员发布了两种旨在减少关系数据领域和面向对象的编程之间的阻抗失谐的产品：LINQ to SQL 和 ADO.NET Entity Framework。借助其中任何一种产品，您不必编写大部分探测代码，即可实现对象持久性。但是，将这些对象关系映射 (ORM) 技术应用到面向服务的应用程序体系结构为应用程序开发人员带来了全新的挑战。

　　例如，如何创建将对象持久性与应用程序其他部分分离的数据访问层 (DAL)，以便在需要时使用一个 ORM 提供程序换出另一个提供程序。如何在客户端没有安装 LINQ to SQL 或Entity Framework的情况下跟踪对实体的更改？如何通过仅调用服务一次即可在单个事务中插入、更新和删除多个实体？

在本文中，我将进行简要介绍并提供一些有关如何解决上述问题的建议。首先，我将基于 Northwind 示例数据库创建一个用于处理订单的 DAL。DAL 的两种实现（一种使用 LINQ to SQL，一种使用Entity Framework）依赖于一个接口（请参见图 1）。LINQ to SQL 和Entity Framework都具有基于数据库架构生成实体的工具，但是 DAL 并不使用这些实体，而是仅公开通常忽略涉及到持久性的数据传输对象 (DTO)。

　图 1 适用于订单处理应用程序的面向服务的体系结构

LINQ to SQL 和Entity Framework使用不同的方法持久化断开连接的实体，具体取决于要创建新实体还是更新现有的实体。因此，为了调用合适的 API，您必须事先了解实体的状态。例如，如果您具有 UpdateOrder 方法接受带有订单明细的订单，可以为 UpdateOrder 方法添加三个参数，以接受创建、更新和删除的订单明细。但这很容易因探测订单明细而使方法签名变得混乱。

　　此外，您可以带外传递更改状态信息（例如在 SOAP 或 HTTP 标头中传递），但这样做会使更改跟踪与通信协议相结合。下面我将介绍另一种方法 — 将更改状态作为每个实体的数据约定的一部分，我建议使用这种方法：

[DataContract]
public enum TrackingInfo
{
[EnumMember]
Unchanged,
[EnumMember]
Created,
[EnumMember]
Updated,
[EnumMember]
Deleted
}

除了其他属性之外，每个 DTO 都有一个使用 TrackingInfo 枚举的 TrackingState 属性。双方只需同意此数据约定即可。

虽然我为每个 DTO 添加了 TrackingState 属性，但我还必须依赖没有安装 LINQ to SQL 或Entity Framework的客户端来跟踪创建、更新或删除的对象，以及将 TrackingState 属性设置为相应的值（请参见图 1）。我创建了一个通用更改跟踪集合来执行此任务。此集合有两种类型：一种扩展 ObservableCollection<T> 以用于 Windows Presentation Foundation (WPF) 应用程序；一种扩展 BindingList<T> 以用于 Windows 窗体应用程序。每种集合都可在从集合中删除项目之前缓存删除的项目，并且每种集合都具有 GetChanges 方法，该方法只返回插入、更新或删除的项目。

创建数据访问层

DAL 有助于将应用程序的其他部分与对象持久性的详细信息隔离开。为此，通过 DAL 公开的对象必须排除任何特定数据访问技术的其余部分。LINQ to SQL 和Entity Framework允许您使用命令行工具和 Visual Studio 设计器创建实体，但是这些代码生成的实体中的一些项目与它们的源相悖。

例如，为了支持关联对象的延迟加载，LINQ to SQL 使用 EntityRef<T> 和 EntitySet<T> 集合类型表示数据关系，而Entity Framework使用 EntityReference<T> 和 EntityCollection<T> 表示导航属性。此外，这些实体添加了旨在支持客户端服务器方案（例如使用局部方法的验证和使用 INotifyPropertyChanged 的数据绑定）的代码元素，如果这些实体只用于与 Windows Communication Foundation (WCF) 服务进行通信，则无需使用这些代码元素。

　　由于 LINQ to SQL 和Entity Framework支持使用 DataContractSerializer 对实体进行序列化（使用 DataContract 和 DataMember 属性进行标记），因此您可能希望将它们用于您的服务操作中，而无论这样做会带来多大的负担。毕竟，当您设置 WCF 服务引用时，集合类型（如 LINQ to SQL 和Entity Framework使用的集合类型）在客户端上显示为简单数组。

　　但是，如果您将 LINQ to SQL DataContext 的 SerializationMode 从“None”设置为“Unidirectional”，则只有一对多关系中的“多”方标有 DataMember 属性。这表示如果您的 Order 实体有 Customer 和 Order_Details 两个属性，只有 Order_Details 标有 DataMember 并包含在数据约定中，而 Customer 则不能如此。另一方面，Entity Framework包含的字段可能比您希望包含在数据约定中的要多，从而在客户端上生成用以实现特定于Entity Framework的功能的类，例如，EntityKey、EntityKeyMember、EntityObject 或 EntityReference。

鉴于上述原因，您应该避免通过 DAL 公开 LINQ to SQL 或Entity Framework工具生成的实体，改为返回简单的 DTO，它们存在的目的只是跨服务边界传送数据。例如，Order DTO（请参见图 2）只包含属性，不包括方法。所有的 DTO 均在 DataTransferObjects 命名空间中定义，以与工具生成的同名类进行区分。

图 2 表示 Northwind 中的订单的 DTO

namespace DataTransferObjects
{
[DataContract]
public class Order
{
[DataMember]
public int OrderID { get; set; }
[DataMember]
public string CustomerID { get; set; }
[DataMember]
public string CustomerName { get; set; }
[DataMember]
public DateTime? OrderDate { get; set; }
[DataMember]
public List<OrderDetail> OrderDetails { get; set; }
[DataMember]
public byte[] Updated { get; set; }
[DataMember]
public TrackingInfo TrackingState { get; set; }
}
}

　　灵活的 DAL 应该可以使 Order Service 不受基础持久性技术更改的影响。例如，假设您选择使用 SQL Server 来存储数据并且您的对象模型和数据库架构极其类似，因此，您决定使用 LINQ to SQL 持久化对象。但是，当您编写 LINQ to SQL 持久性逻辑后不久，您决定使用其他数据库系统（如 Oracle）或希望使用Entity Framework的映射功能来分离概念架构和逻辑架构。或许一种新的数据访问技术已推出，您希望使用该技术。如果您设计了基于插件体系结构的灵活 DAL，则应该可以根据 app.config 中的条目随时切换提供程序。

　　为实现此灵活性，我创建了 IDataProvider 接口，该接口具有用以检索和更新客户订单，以及检索支持的客户和产品信息的方法（请参见图 3）。本示例应用程序包括两个实现 IDataProvider 的类：使用 LINQ to SQL 的 SqlDataProvider；使用Entity Framework和 LINQ to Entities 的 EntityDataProvider（请参见图 1）。您仅可以为 DAL 的 app.config 文件中的“DataProvider”设置输入完全限定的类名称，并使用 Assembly 类的 CreateInstance 方法创建此类的实例，从而将其转换为 IDataProvider。Order Service 对实现 IDataProvider 而使用的类没有特别要求，因此您可以选择任何数据提供程序：

IDataProvider provider =
Assembly.GetExecutingAssembly()
.CreateInstance(Settings.Default.DataProvider, true)
as IDataProvider;

图 3 将 DAL 与接口分离

namespace DataAccessLayer
{
// Alias the namespace containing Data Transfer Objects
using DTO = DataTransferObjects;
public interface IDataProvider
{
// Retrieve Customers, Products, Orders
DTO.Customer[] GetCustomers();
DTO.Product[] GetProducts();
DTO.Order[] GetCustomerOrders(string customerID);
// CRUD operations for Order
DTO.Order GetOrder(int orderID);
DTO.Order CreateOrder(DTO.Order order);
DTO.Order UpdateOrder(DTO.Order order);
void DeleteOrder(DTO.Order order);
}
}

　　默认情况下，LINQ to SQL 和Entity Framework会在与项目相同的命名空间中生成实体。但是，如果将新的“LINQ to SQL Classes”项目置于 L2S 项目文件夹中，此工具会使用此文件夹名作为嵌套的命名空间，这有助于区分 LINQ to SQL 实体和 DTO 实体。同样，如果将新的“ADO.NET Entity Data Model”置于 L2E 项目文件夹中，Entity Framework实体也会存在于嵌套的 L2E 命名空间。另外，您可以在 LINQ to SQL 的属性窗口和Entity Framework可视组件设计器中指定命名空间。

　　此处，我选择为 LINQ to SQL 和Entity Framework两者生成实体，并将查询结果转换为 DTO。此时还存在以下两种可能性：完全消除工具生成的实体；使用 XML 文件映射 DTO。Entity Framework 已使用了 XML 映射文件，但是在Entity Framework的第一个版本中，使用简单的 C# 对象 (POCO) 根本无法实现完全的持久化透明 (PI)。在版本 1 中，您可以实现此目标，但实体必须首先实现两个接口：IEntityWithRelationships 和 IEntityWithChangeTracking，因此这种情况需要使用 IPOCO（POCO + 接口）。.希望Entity Framework的将来版本能够改进对 POCO 和持久化透明的支持。

LINQ to SQL 确实能够很好地支持使用 XML 映射文件将 POCO 映射到数据库架构。但是，从 L2S.Order 或 L2E.Order 投影到 DTO.Order 提供了更大程度的灵活性。例如，图 4 显示的 SqlDataProvider 的 GetOrder 方法，此方法根据 L2S.Order Customer 属性的 ContactName 属性填充 DTO.Order 的 CustomerName 属性，实际上恰恰反映了 Customer 和 Order 之间的关系。同理，我也可以根据 L2S.Order_Detail 的 Product 属性设置 DTO.OrderDetail 的 ProductName 属性。在每一种情况下，我都必须将 DataContext 的 LoadOptions 属性配置为预先加载 LINQ to SQL 实体。

图 4 GetOrder 方法使用 LINQ to SQL 框架返回 DTO.Order

namespace DataAccessLayer
{
using DataAccessLayer.L2S;
using DTO = DataTransferObjects;
public class SqlDataProvider : IDataProvider
{
public DTO.Order GetOrder(int orderID)
{
using (NorthwindDataContext db = new NorthwindDataContext
(Settings.Default.NorthwindSqlConnection))
{
// Set load options
DataLoadOptions opts = new DataLoadOptions();
opts.LoadWith<Order>(o => o.Customer);
opts.LoadWith<Order>(o => o.Order_Details);
opts.LoadWith<Order_Detail>(od => od.Product);
db.LoadOptions = opts;
// Create a DTO.Order from the L2S.Order
DTO.Order order =
(from o in db.Orders
where o.OrderID == orderID
select new DTO.Order
{
OrderID = o.OrderID,
CustomerID = o.CustomerID,
CustomerName = o.Customer.ContactName,
OrderDate = o.OrderDate,
Updated = o.Updated.ToArray(),
OrderDetails =
(from od in o.Order_Details
select new DTO.OrderDetail
{
OrderID = od.OrderID,
ProductID = od.ProductID,
ProductName = od.Product.ProductName,
Quantity = od.Quantity,
UnitPrice = od.UnitPrice,
Updated = od.Updated.ToArray()
}).ToList()
}).Single();
return order;
}
}
}
}

　　现在让我们回到 EntityDataProvider 的 GetOrder 方法，该方法使用 LINQ to Entities 基于 L2E.Order 返回 DTO.Order（请参见图 5）。注意，Include 运算符用于预先加载 Order_Details 和 Order_Details.Product 属性。（有关 LINQ 运算符的详细信息，请参见数据点专栏“LINQ 的标准查询运算符”）。Entity Framework和 LINQ to SQL 都没有提供现成的延迟加载功能，因此您必须明确指出希望在查询结果中包含哪些相关实体。检索到指定的订单之后，您可以直接使用它来创建新的 DTO.Order。

图 5 GetOrder 方法使用 LINQ to Entities 返回 DTO.Order

namespace DataAccessLayer
{
using DataAccessLayer.L2E;
using DTO = DataTransferObjects;
public class EntityDataProvider : IDataProvider
{
public DTO.Order GetOrder(int orderID)
{
using (NorthwindEntities db = new NorthwindEntities
(Settings.Default.NorthwindEntityConnection))
{
// Get the specified L2E.Order
Order nwOrder =
(from o in db.OrderSet
.Include("Order_Details")
.Include("Order_Details.Product")
where o.OrderID == orderID
select o).First();
// Create a DTO.Order from the L2E.Order
DTO.Order order = new DTO.Order
{
CustomerID = nwOrder.CustomerID,
CustomerName = (from c in db.CustomerSet
where c.CustomerID == nwOrder.CustomerID
select c).First().ContactName,
OrderID = nwOrder.OrderID,
OrderDate = nwOrder.OrderDate,
Updated = nwOrder.Updated,
OrderDetails =
(from od in nwOrder.Order_Details
select new DTO.OrderDetail
{
OrderID = od.OrderID,
ProductID = od.ProductID,
ProductName = od.Product.ProductName,
Quantity = od.Quantity,
UnitPrice = od.UnitPrice,
Updated = od.Updated
}).ToList()
};
return order;
}
}
}
}

持久化各个对象

LINQ to SQL 和Entity Framework采用不同的方法持久化断开连接的实体。例如，假设您希望创建具有一个或多个订单明细的新订单。如图 6 所示，LINQ to SQL 至少需要两行代码：一行代码调用 InsertOnSubmit 以插入订单，一行代码使用 InsertAllOnSubmit 插入订单的明细项目。而Entity Framework只需要您将订单添加到 ObjectContext 的 OrderSet，它会自动添加完整的对象图表（请参见图 7）。LINQ to SQL 和Entity Framework都采用以下操作过程：首先插入父订单、获取 OrderID 值（数据库中的标识列），然后插入子订单明细。

图 6 使用 LINQ to SQL 创建订单

public DTO.Order CreateOrder(DTO.Order order)
{
// Insert new order
using (NorthwindDataContext db = new NorthwindDataContext
(Settings.Default.NorthwindSqlConnection))
{
// Create an L2S.Order
Order nwOrder = new Order
{
OrderID = order.OrderID,
CustomerID = order.CustomerID,
OrderDate = order.OrderDate,
Updated = order.Updated
};
// Add order details
nwOrder.Order_Details.AddRange(
from od in order.OrderDetails
select new Order_Detail
{
OrderID = od.OrderID,
ProductID = od.ProductID,
Quantity = od.Quantity,
UnitPrice = od.UnitPrice,
Updated = od.Updated
});
// Insert order and order details separately
db.Orders.InsertOnSubmit(nwOrder);
db.Order_Details.InsertAllOnSubmit(nwOrder.Order_Details);
db.SubmitChanges();
// Return the updated order
return GetOrder(nwOrder.OrderID);
}
}

图 7 使用 LINQ to Entities 创建订单

public DTO.Order CreateOrder(DTO.Order order)
{
using (NorthwindEntities db = new NorthwindEntities
(Settings.Default.NorthwindEntityConnection))
{
// Create an L2E.Order
Order nwOrder = new Order
{
OrderID = order.OrderID,
CustomerID = order.CustomerID,
OrderDate = order.OrderDate,
Updated = order.Updated
};
// Add order details
foreach (DTO.OrderDetail od in order.OrderDetails)
{
Order_Detail detail = new Order_Detail
{
Order = nwOrder,
Product = (from p in db.ProductSet
where p.ProductID == od.ProductID
select p).First(),
Quantity = od.Quantity,
UnitPrice = od.UnitPrice,
Updated = od.Updated
};
nwOrder.Order_Details.Add(detail);
}
// Add order and order details
db.AddToOrderSet(nwOrder);
db.SaveChanges();
// Return the updated order
return GetOrder(nwOrder.OrderID);
}
}

　　在介绍删除或更新实体之前，我需要首先介绍一下如何处理并发问题。LINQ to SQL 要求您附加一个断开连接的实体才能调用 DeleteOnSubmit。这样做系统会提示您使用 LINQ to SQL 执行最优的并发检查，如果用户尝试删除其他用户已经更改的项目，则删除将会失败，并发出 ChangeConflictException。实际上确实没有简单方法可以关闭此行为，因为如果您尝试在不调用 Attach 的情况下调用 DeleteOnSubmit，LINQ to SQL 将会引发 InvalidOperationException。但是，Entity Framework并不强制您在删除实体时处理更改冲突（请参阅本文附带的代码下载）。

　　图 8 显示了使用 LINQ to SQL 更新订单的代码。请注意，Attach 方法接受 bool 类型的 asModified 参数。对 LINQ to SQL 来说，将此参数设置为“True”表示您希望将时间戳列用于并发管理。这样做会使 LINQ to SQL 将当前的时间戳值包含到 SQL Update 语句的 WHERE 子句中。当其他用户更新此记录时，此更新不会影响任何行，并且 LINQ to SQL 将引发 ChangeConflictException。

图 8 使用 LINQ to SQL 更新订单

public DTO.Order UpdateOrder(DTO.Order order)
{
using (NorthwindDataContext db = new NorthwindDataContext
(Settings.Default.NorthwindSqlConnection))
{
// Create an L2S.Order
Order nwOrder = new Order
{
OrderID = order.OrderID,
CustomerID = order.CustomerID,
OrderDate = order.OrderDate,
Updated = order.Updated
};
// Attach and save order
db.Orders.Attach(nwOrder, true);
db.SubmitChanges();
// Return the updated order
return GetOrder(order.OrderID);
}
}

　　使用此策略，客户端既不需要保留原始值也不需要将其随更新一起提交，而是将这些值传递到 Attach 方法的其他重载。系统对此列的命名方式没有要求，只需包含时间戳数据类型即可。当您将具有时间戳列的表添加到 Visual Studio 的 LINQ to SQL 设计器之后，所有实体字段的 UpdateCheck 属性将设置为 Never，并且 LINQ to SQL 将使用时间戳来检查更改冲突。

　　当前，相对于 LINQ to SQL 来说，使用Entity Framework更新实体和管理并发稍微有些复杂，因为即使在并发管理中使用时间戳列，它也需要实体的原始值（请参见图 9）。（这一方面可能会在Entity Framework的下一版本中获得改善。）由于客户端未提供原始订单，您需要从数据库中检索此订单并将其 Updated 属性设置为客户端提供的值，此“原始”值才是您真正需要的值。请确保提交对 Updated 的更改，方法为：分离并重新将订单附加到对象上下文，或者调用 AcceptAllChanges。然后，调用 ApplyPropertyChanges 使用更新订单所提供的值更新原始订单。此外，还需要执行一个步骤，Entity Framework才能使用时间戳列进行并发检查：即，在 Order 实体上将 Updated 属性的 ConcurrencyMode 值从“None”设置为“Fixed”（请参见图 10）。

图 9 使用 LINQ to Entities 更新订单

public DTO.Order UpdateOrder(DTO.Order order)
{
using (NorthwindEntities db = new NorthwindEntities
(Settings.Default.NorthwindEntityConnection))
{
// Get original order using key from updated order
EntityKey key = db.CreateEntityKey("OrderSet",
new Order { OrderID = order.OrderID });
Order origOrder = db.GetObjectByKey(key) as Order;
// Set Updated to match DTO.Order - (for concurrency)
origOrder.Updated = order.Updated;
// Commit change to the Updated property
db.Detach(origOrder);
db.Attach(origOrder);
// Create a NW order for updating the original order
Order updatedOrder = new Order
{
OrderID = order.OrderID,
OrderDate = order.OrderDate,
CustomerID = order.CustomerID,
Updated = order.Updated
};
// Apply changes to the original order
db.ApplyPropertyChanges("OrderSet", updatedOrder);
// Persist changes
db.SaveChanges();
// Return the updated order
return GetOrder(order.OrderID);
}
}

　　图 10 将 Updated 的 ConcurrencyMode 设置为“Fixed”

　　跨服务边界跟踪更改

如果您希望仅调用服务一次即可在同一事务中持久化多个实体的更改，您需要使用一种方法来确定每个实体的更改状态。这就是示例应用程序中的每个 DTO 都包含 TrackingState 属性的原因。如果客户端已经设置了此属性，DAL 即可以使用合适的 LINQ to SQL 或Entity Framework API 持久化对断开连接的实体的插入、更新和删除。这样做允许将 DTO 数组传递到服务操作进行批量更新，以便使用简单的 LINQ to Objects 查询找到插入、更新或删除的订单明细。例如，要想只获得添加到订单的订单明细，您可以使用 TrackingState Created 在集合中查询此类项目：

List<Order_Detail> insertedDetails =
(from od in order.OrderDetails
where od.TrackingState == TrackingInfo.Created
select new Order_Detail
{
OrderID = od.OrderID,
ProductID = od.ProductID,
Quantity = od.Quantity,
UnitPrice = od.UnitPrice,
Updated = od.Updated == null ? new byte[0] : od.Updated
}).ToList();

您必须将 Updated 的 null 值转换为空字节数组，因为数据库表中的时间戳列通常不能为空。获得插入的订单明细的列表后，您可以使用合适的 LINQ to SQL API 通过传递订单明细集合来添加新实体：

db.Order_Details.InsertAllOnSubmit(insertedDetails);

　　和您预想的一样，有 AttachAllOnSubmit 和 DeleteAllOnSubmit 方法可满足您的需要。当对 DataContext 调用 SubmitChanges 时，LINQ to SQL 会确保按正确的顺序提交这些更改（对插入项目使用父子顺序，对删除项目使用子父顺序），并且将所有的操作包含在一个事务中。您可以借助相同的方法使用 LINQ to Entities 持久化订单明细。有关适用于 LINQ to SQL 和Entity Framework的 UpdateOrder 的完整代码列表，请参阅下载内容。

　　现在，很明显就可以看出 DAL 依靠客户端跟踪每个 DTO 的更改状态。客户端上跟踪对象更改的最方便机制是泛型集合。为了使集合能够更新 TrackingState 属性，应该约束类型参数以实现接口。（您还可以使用 Reflection 获得和设置 TrackingState 属性，但泛型类型约束可提供类型安全性和更好的性能。）输入只包含 TrackingState 属性的 ITrackable 接口：

public interface ITrackable
{
TrackingInfo TrackingState { get; set; }
}

正如我前面提及到的，跟踪更改集合有两种类型：一种用于 Windows 窗体，扩展 BindingList<T>；一种用于 WPF 应用程序，扩展 ObservableCollection<T>。我并没有在这两个集合中重复更改跟踪逻辑，而是将此逻辑集中到 ChangeTrackingHelper<T> 类中，此类从 Collection<T> 派生并约束 T 以实现 ITrackable（请参见图 11）。此外，它还约束 T 以实现 INotifyPropertyChanged，以便处理每个项目的 PropertyChanged 事件以及将 TrackingState 属性设置为 Updated。

图 11 更改跟踪帮助程序类

internal class ChangeTrackingHelper<T> : Collection<T>
where T : ITrackable, INotifyPropertyChanged
{
Collection<T> deletedItems = new Collection<T>();
// Listen for changes to each item
private bool tracking;
public bool Tracking
{
get { return tracking; }
set
{
foreach (T item in this)
{
if (value) item.PropertyChanged += OnItemChanged;
else item.PropertyChanged -= OnItemChanged;
}
tracking = value;
}
}
void OnItemChanged(object sender, PropertyChangedEventArgs e)
{
if (!Tracking) return;
ITrackable item = (ITrackable)sender;
if (e.PropertyName != "TrackingState")
{
// Mark item as updated
if (item.TrackingState == TrackingInfo.Unchanged)
item.TrackingState = TrackingInfo.Updated;
}
}
// Mark item as created and listen for property changes
protected override void InsertItem(int index, T item)
{
if (!Tracking) return;
item.TrackingState = TrackingInfo.Created;
item.PropertyChanged += OnItemChanged;
base.InsertItem(index, item);
}
// Mark item as deleted and cache it
protected override void RemoveItem(int index)
{
if (!Tracking) return;
T item = this.Items[index];
if (item.TrackingState != TrackingInfo.Created)
{
item.TrackingState = TrackingInfo.Deleted;
item.PropertyChanged -= OnItemChanged;
deletedItems.Add(item);
}
base.RemoveItem(index);
}
public ChangeTrackingHelper<T> GetChanges()
{
// Create a collection with changed items
ChangeTrackingHelper<T> changes = new ChangeTrackingHelper<T>();
foreach (T existing in this)
{
if (existing.TrackingState != TrackingInfo.Unchanged)
changes.Add(existing);
}
// Append deleted items
foreach (T deleted in deletedItems)
changes.Add(deleted);
return changes;
}
}

　　将项目添加到集合后，其 TrackingState 将设置为 Created。项目删除后，其 TrackingState 将设置为 Deleted，并缓存在已删除项目的集合中。在进行跟踪之前，用户应该首先将集合的 Tracking 属性设置为 True，以便集合订阅每个项目的 PropertyChanged 事件。GetChanges 方法会创建一个新的 ChangeTrackingHelper 集合，其中仅包含标记为创建、更新或删除的项目。

　　配置客户端

我们已经了解了一组通用的跟踪更改集合，现在可以派上用场了！我已将这些集合放置在一个单独类库中，因此您只需从客户端应用程序中引用即可。但是，当您向客户端项目添加服务引用时，您必须执行一些其他步骤，集合才能使用 svcutil.exe 生成的类。虽然 Customer、Product、Order 和 OrderDetails 等类已经具有了 TrackingState 属性，但它们不会实现 ChangeTrackingHelper<T> 所需的 ITrackable 接口。

另外，必须将 TrackingInfo 枚举放置在跟踪更改集合可以找到的命名空间，但不是嵌套命名空间，因为 svcutil.exe 会在您添加服务引用时将其置于此处。最后，如果服务操作返回的对象数组在客户端应用程序中显示为跟踪更改集合，那就更好了。因为这样会使 Order.OrderDetails 的数据类型设置为 ChangeTrackingCollection<T> 或 ChangeTrackingList<T>（而非 OrderDetail 数组），从而减少向服务发送已更改的订单明细的工作量。

　　要设置 Windows 窗体或 WPF 客户端应用程序，使其使用跟踪更改集合跟踪实体更改并将这些更改发送至服务，需要遵循以下步骤。务必按照给定顺序执行以下步骤：

　　在 Windows 窗体或 WPF 客户端应用程序中，设置对 ClientChangeTracker 类库项目或程序集（ITrackable 接口和跟踪更改集合放置位置）的引用。

　　在 WCF 服务应用程序运行的过程中，添加指向元数据终点或 Web 服务描述语言 (WSDL) URL 的服务引用。在添加服务引用之前，引用 ClientChangeTracker 程序集非常重要。默认情况下，服务引用将重用所有引用程序集中的类型，并且由于 ClientChangeTracker 包含的 TrackingInfo 枚举具有 DataContract 和 EnumMember 序列化属性，svcutil.exe 会重用此枚举而不会将其复制到服务引用创建的 Reference.cs 代码文件中。

　　设置服务引用之后，为服务引用创建的每个 DTO 类添加局部类。例如，如果您的服务操作公开了 Customer、Product、Order 和 OrderDetail 对象，它们都将包含在服务引用中。如果显示项目的所有文件并展开服务引用和 Reference.svcmap 节点，您会在 Reference.cs 中看到这些类。记下它们所属的命名空间（应该与您添加服务引用时指定的位置一致）。现在将类文件添加到项目中并更改命名空间，以在 Reference.cs 中反映此命名空间。在此命名空间中，为每个 DTO 类添加公共局部类并实现 ITrackable 接口：

namespace WpfClient.OrderService
{
public partial class Customer : ITrackable { }
public partial class Product : ITrackable { }
public partial class Order : ITrackable { }
public partial class OrderDetail : ITrackable { }
}注意 TrackingState 属性缺失的情况。由于此属性作为每个 DTO 数据约定的一部分包含在代码生成的类中，因此您无需在此处插入该属性。为了在应用程序中更加轻松地使用这些类，您还可以在这些类中插入其他代码，例如，初始化类的构造函数（使用 new 创建类时调用；WCF 创建类时不调用）。有关示例，请参阅代码下载。

最后，您可能希望将服务引用配置为使用 ChangeTrackingCollection<T> 或 ChangeTrackingList<T> 作为集合类型，而不是 System.Array。这表示当服务操作返回 Order 数组时，将在客户端上具体化为 ChangeTrackingCollection<Order> 或 ChangeTrackingList<Order>。每个 Order 的 OrderDetails 属性都有可能显示为跟踪更改集合类型。知道这有多酷了吧？要想实现这种奇妙的转变，您必须打开 Reference.svcmap 文件（显示所有项目文件并打开服务引用进行查看）然后深入研究 XML。对于 WPF 客户端，按如下所示配置 CollectionMappings 元素：

　　对于 Windows 窗体客户端，您应该将 ChangeTracker.ChangeTrackingCollection`1 替换为 ChangeTracker.ChangeTrackingList`1。

　　现在，在服务应用程序运行过程中，右键单击服务引用并选择“更新服务引用”，然后重新编译客户端应用程序。如果一切顺利，则会成功构建项目，您将可以继续执行操作。

　　完成这些步骤之后，剩下的就是为客户端应用程序编写代码以检索某些 DTO 并将它们绑定到 UI（用户可以在此处更新 DTO 并将其发送回服务以保存到数据库中）。从服务中检索对象只需要创建一个服务代理实例并调用操作来获取 Customer、Product 和 Order 即可。例如，如果服务包含的 GetOrder 方法接受 Int 类型的 OrderId，那么您的客户端代码可能如下所示：

using (OrderServiceClient proxy = new OrderServiceClient())
{
CurrentOrder = proxy.GetOrder(orderId);
}

　　如果您的数据绑定设置正确，订单和订单明细都应该显示在用户界面上。图 12 显示了示例应用程序在 WPF 客户端中的显示。单击“Get Order”按钮，用户可以检索某个现有订单，以及从客户订单列表中进行选择；单击“New Order”按钮可直接创建新订单；单击“Delete Order”按钮，用户可对服务器代理调用 DeleteOrder，从而删除当前订单。

　　图 12 示例 WPF 客户端应用程序

　　单击“Save Order”按钮，可以调用服务 CreateOrder 操作以持久化最新创建的订单，或调用 UpdateOrder 操作保存对现有订单的更改。这两种操作都会返回一个订单对象，其中包含用于并发管理的当前 Updated 属性和用于插入订单的新 OrderId 属性（Northwind 中 Order 表使用标识列）。获得更新订单后，您即可以启动更改跟踪并将数据绑定设置为使用订单。

但是，在保存现有的订单之前，您还需要执行一些操作。我们只希望传递创建、更新或删除的订单明细，而不想浪费网络带宽来发送未发生更改的订单明细。借助 ChangeTrackingCollection<T> 和 ChangeTrackingList<T> 可以比较轻松地实现此目的，因为它们公开的 GetChanges 方法只返回插入、修改或删除的订单明细。调用 UpdateOrder 的代码如图 13 所示。

图 13 调用 UpdateOrder

Order changedOrder = new Order
{
OrderID = CurrentOrder.OrderID,
CustomerID = CurrentOrder.CustomerID,
OrderDate = CurrentOrder.OrderDate,
Updated = CurrentOrder.Updated,
TrackingState = CurrentOrder.TrackingState,
OrderDetails = CurrentOrder.OrderDetails.GetChanges()
};
using (OrderServiceClient proxy = new OrderServiceClient())
{
CurrentOrder = proxy.UpdateOrder(changedOrder);
}

由于我已经将服务引用配置为使用 ChangeTrackingCollection<T> 作为集合类型，因此 Order 类的 OrderDetails 属性应该属于类型 ChangeTrackingCollection<OrderDetail>，并且我可以直接对其调用 GetChanges 只获得添加、修改或删除的订单细节，以传递给 UpdateOrder 操作。另外，由于 ChangeTrackingCollection<T> 可扩展 ObservableCollection<T>，因此它支持的数据绑定功能非常适用于 WPF 应用程序（例如，实现 INotifyCollectionChanged 以便在向集合添加或从集合删除项目时 UI 可以更新项目控件）。同理，由于 ChangeTrackingList<T> 可扩展 BindingList<T>，它可以作为 Windows 窗体 DataGridView 的有效数据源，以利用 BindingList<T> 实现的接口增强用户体验。

　　总结

　　现在您已经拥有了一个面向服务的灵活应用程序体系结构，在此体系结构中，客户端可以完全不考虑对象的持久化方法。我们知道，DTO 允许对对象模型的结构和形状进行更多的控制，这与允许跨服务边界传递工具生成的实体一样具有吸引力。此外，构建数据访问层可将应用程序从您使用的任何持久性技术中分离出来，从而允许您在不影响应用程序的其他部分的情况下更换数据访问实现。

LINQ to SQL 和 ADO.NET Entity Framework的出现代表了 ORM 领域的一次巨大飞跃，有效地减少了对象和关系数据之间的阻抗失谐。它们支持各种方案，包括传统客户端服务器和面向服务的体系结构。但是，对于开发人员来说，使用 DTO 更新数据库需要进行更多的工作，尤其是在使用时间戳值检测并发用户之间的冲突时。但是，通过将更改状态添加到客户端和服务之间的数据约定，您可以附加与源上下文断开连接的实体。最后，我们介绍了通用的跟踪更改集合如何不负众望地管理客户端上的更改状态，使您访问服务一次即可处理批更新。

新的项目架构实现要考虑的方面

2009-05-29T04:38:00Z

通过最近一段时期对Entity Framework和ASP.NET MVC的学习，初步总结出要设计一个新项目所需考虑的方面：

一、数据建模：

存储层数据建模：Entity对象（Entity Objects）。包括：Entity、EntityCollection对象。
域模型设计（DDD）：POCO对象（DTO Objects）、状态跟踪（State Tracking）、数据验证模型Validators。包括：Object、IList对象。
展现层建模：视图模型（View Models）、JSON、JQuery封装。

二、架构实现：

实现底层Repository层：封装Entity Framework数据模型，采用仓储（Repositories）、查询准则（Specifications）、载入策略（Fetching Strategies）获取实体对象（Entity Objects）、操作POCO对象（DTO Objects）与实体对象（EntityObjects）的转换。
中间Service层：封装对POCO的操作，它依赖Repository层。实现事务Transaction功能。
界面展现层：ASP.NET MVC定制扩展。包括：Controllers、Validation、Filters、ModelBinders、MVC控件、分页器（Pagenation）等等。

Data-Layer: EF + Repository Object

Business Layer: B.Objects for each major Entity with Validation and Domain Logic (*made it fine to here with IUpdateable,etc*)

Service Layer: Ado.Net Data Service exposing the Entities as DTO's but from the B.O's logic, not EFs, so I have more control over what it does.

Model Layer: Handle making requests to my SOA Services

Controller Layer: View Layer with Javascript