poco fix-up during relation change

I have a poco entity like following. At first I do not have Items navigation property, but it turns out, this property is important. Bascially it makes the following code work.

var countBeforeInsert = _db.Entities.Count();
            //
            Entity parent = new Entity();
            parent.Id = Guid.NewGuid();
            parent.Name = "parent";
            parent.Created = DateTime.Now;
            parent.LastUpdated = DateTime.Now;

Define entity from "view"

When you have Entity that mapping to more than one table in a database. You probably have options to do the mapping.

The first option is defined import all the tables into the StorageModels, but not ConceptualModels, define you entity without mapping, then manually edit the edmx file and to define the mapping. Because the entity mapping is manual, you need to define the CRUD manually. You can use store proc to do that.

<EntitySetMapping Name="DummyExes">
            <QueryView>
              select value EFTestModel.DummyEx(p.Id, p.c1, p.c2, c.c3)
              from EFTestModelStoreContainer.Dummy as p
              left join EFTestModelStoreContainer.DummyEx as c
              on p.Id = c.DummyId
            </QueryView>
          </EntitySetMapping>

The second option is defined a view in database, import that view and mapping to your entity. Because database view are normally treated readonly, you can define CRUD operation using stored proc, just like QueryView. Or you edit edmx file, cheat the ef runtime to think the view as talbe, then define insteadof trigger to do the update.

supporting state management for poco object in object context

var entry = context.ObjectStateManager.GetObjectStateEntry(poco);

For the Entity Framework to create the change-tracking proxies for your POCO classes, the following conditions must be met,

1. The class must be public, non-abstract, and non-sealed.

2. The class must implement virtual getters and setters for all properties that are
persisted.

3. You must declare collection-based relationships navigation properties as
ICollection<T>. They cannot be a concrete implementation or another interface
that derives from ICollection<T>.

Functional aspect of c#

Two generic delegate in c#, makes c# look more like a functional language, they are Action<T>, Func<T1, T2, ...>. The functional feature let you easily express your algorithm, without using the traditional design pattern. These delegates can be compared with function in javascript, and lamda in other language. For example,

interface IStrategy
{
   void Execute(object o);
}

Using design pattern, we have to write a more code to aggregate different strategies. But using Action<T> is more succinct.

Action<object> oldAction = ... ;//
Action<object> newAction = (o) => { Console.Write("preAction"); oldAction(o); Console.Write("postAction"); }
newAction(o);

If we want to go a step further, we can use function(lamda, delegate) to create functions. For example:

Func<Action<object>, Action<object>> createFunc = (func) => 
{
   return (o) => { 
             Console.Write("preAction"); 
             func(o); 
             Console.Write("postAction"); 
          };
}

Return statement in javascript

return expression;
//or
return;

If there is no expression, then the return value is undefined. Except for constructor, whose return value is this