Montag, 23. Januar 2017

Handling child collectins in Entity Framework Code First

There are a lot of blog posts out there on the issue of removing items from child collections in Entity Framework.

The Problem

The Problem is, that when you remove an item from a child collection of an entity, EF just sets the foreign key null in the child collections table. It does not delete the item. While this means that the item does no longer appear in your collection, it is not a satisfying situation as it leaves orphaned records around.

Possible solutions and problems with the solutions

There are three possible solutions to the problem:
  1. Explicitly remove the child
  2. Identifying Relationships
  3. SaveChanges
The first one means, that whenever you remove something from a child collection you remove it from the according DbSet-Property of your context as well. This is obviously a bad design, becaus for child collection I do not want a DbSet collection of its own.
The second one means that you need to make the primary key of the parent part of the primary key of the child. This is bad because I need to change my model and bloat it with unnecessary properties - even worse these properties merely contain technical database stuff.  
The third one comes close to a good solution, but not the way I like to handle it. It requires to override the SaveChanges method of the context and handle deleting orphans there. This is the best solution so far because it tackles the problem close to its origin: inside the technical EF code stuff. But almost any implementations on the web tend to do it in a way that comes close to solution 2: the have kind of a navigation propertey in the child that points to the parent and that can be checked for null. Others suggest using domain events, which is generally a great concept but it feels weired to introduce it to solve a infrastructural problem.

My context

So here is my context, the scenario was from a coding dojo we did. It is a very database focused and very simplified implementation of a shopping cart:

public class Basket
{
    public Guid Id { get; set; }
    public Guid CustomerId { get; set; }
    public virtual IList<BasketItem> Positions { get; set; }
}

public class BasketItem
{
    public int Id { get; set; }
    public string ArticleName { get; set; }
    public decimal Amount { get; set; }
    public decimal Price { get; set; }
}

public class BasketContext : DbContext
{
    public BasketContext() : base("BasketContext") 
    {
    }
    
    public DbSet<Basket> Baskets { get; set; }
}

That is it. You see that Basket has a Guid-Id while BasketItem has an int-Id. This reflects the fact that I consider Basket to be an Aggregate Root on the level of my domain model, while Basket Item is just a contained entity, that does not have an id that is relevant outside of its containing basket. The need for the id is just for the sake of a relational database.
So, when searching for a solution to my problem, I made the following premise, stated loud and clear:
"I will try as hard as I can (very very hard) to never change my model just for the sake of a relational database!"
Having said that, all solutions I found on the web are not for me. Because as my requirements were, my model has no need for a Basket property, or even worse a BasketId property, on the BasketItem. This renders the above options 2 and 3 useless. Option 1 is useless as it requires me to add a DbSet for BasketItems, which is not necessary as they dont get queried directly.

My (prototype) solution

The following solution is not production ready. It is the solution I found in a late-at-the-day hacking session after the dojo that brought the problem to the surface. It ignores edge cases. It is not tested well. Keep that in mind, and dont say I did not warn you.
The solution follows pattern number three from the above solutions, overriding SaveChanges(). But it does not require to fiddle around with your model. My idea was: if EF knows that it has to set a value in table to null, it must be able to find out for me as well.

public override int SaveChanges()
{
    var objectContext = ((IObjectContextAdapter) this).ObjectContext;
    
    objectContext.DetectChanges();

    var deletedThings =
        objectContext.ObjectStateManager.GetObjectStateEntries(EntityState.Deleted).ToList();

   
    foreach (var  deletedThing in deletedThings)
    {
        if (deletedThing.IsRelationship)
        {
            var deletedKey = deletedThing.OriginalValues[1] as EntityKey;
            var entityToDelete = objectContext.GetObjectByKey(deletedKey);
            objectContext.DeleteObject(entityToDelete);
        }
    }

    return base.SaveChanges();
}

This can not be done using the DbContext-Api, but needs to be done with the ObjectContext-Api, so we have to obtain it using the IObjectContextAdapter interface. We need to call DetectChanges, otherwise the deletedThings are empty. In case of an orphaned child entry, the deletedThings contain entries for relationships (deletedThing.IsRelationship yields true). In that case we can find the ends of the relationship in the OriginalValues. A two element array where index 0 points to the parent (the basekt in the example) and index 1 points to the child (the BasketItem). By "points to" I mean that the OriginalValues contains an EntityKey-object identifying the object in question. So using GetObjectByKey(deletedKey) we can load the orpahned child. We must delete it using DeleteObject(entityToDelete) because there is no explicit EntitySet holding it.

I hope someone might find it useful.

Dienstag, 3. Januar 2017

Performance Profiling WCF Service running in WCF Test Client

I know the topic itself sounds a bit old school, but despite what many of my colleagues say, I think WCF is still alive and you might encounter it along your way. Furthermore I found it surprisingly hard to get the configration right to use Visual Studio Performance Profiling on a WCF Service that is running in the WCF Test Client - and is therefore not (yet) deployed to IIS. I mean the kind of WCF Application that you can start by simply hitting F5 and get going using the test client.

So as a note to myselft and hopefully as a help for someone else, here ist how I did it.

Choose Analyze | Performance Profiler (Alt + F2 using the standard shortcuts). Then go through the Performance Wizard.

Page 1 of 4: Specify the profiling method

Choose Instrumentation.

Page 2 of 4: Choose the modules to profile using the instrumentation method

Choose One or more available projects and select the WCF Service Project.

Page 3 of 4: These are things you may want to specify about the non-launchable project(s) you are going to profile

This is the tricky one. The thing is, to use the test client you must not start the test client. You must start the WCF Test Service Host. So set the Executeable path to

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\WcfSvcHost.exe

Modyfiy the path as needed for your Visual Studio version. As Command-line arguments pass the following:

/service:<YourServiceProjectName>.dll /config:<YourServiceProjectName>.dll.config

Fill in the the name of your service project appropriately. The name of the config file points to the app.config file in your project, which is being renamed during compilation. As Working directory set

C:\<Path to my service library project>\bin\Debug\

Page 4 of 4: You have completed specifying settings for your new performance session

You might probably want to uncheck the Launch profiling after the wizard finishes checkbox to check the settings that have been created.

Tweaking the settings

Now your performance Wizard should look like this. That was not the final soultion for me, I needed to further tweak these settings.

Figure 1: The performance profiler after finishing the wizard

So, open the properties of your service project node. On the launch tab check Override project settings and repeat the settings you did before:
Executable to launch: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\WcfSvcHost.exe 
Arguments: /service:<YourServiceProjectName>.dll /config:<YourServiceProjectName>.dll.config
Working Directory: C:\<Path to my service library project>\bin\Debug\

Then delete the second node. You might as well delete the first node and rename the second. Maybe the intial version works too, but I ended up with this after running a profiling session:

Figure 2: The final performance profiler after running a session

For the records, here is the content of my .psess file, of course names and Guids will differ in your file, but sometimes it helps to have just the bits:

<?xml version="1.0" encoding="UTF-8"?>
<VSPerformanceSession Version="1.00">
  <Options>
    <Solution>WCFServices.sln</Solution>
    <CollectionMethod>Instrumentation</CollectionMethod>
    <AllocationMethod>None</AllocationMethod>
    <AddReport>true</AddReport>
    <ResourceBasedAnalysisSelected>true</ResourceBasedAnalysisSelected>
    <UniqueReport>Timestamp</UniqueReport>
    <SamplingMethod>Cycles</SamplingMethod>
    <CycleCount>10000000</CycleCount>
    <PageFaultCount>10</PageFaultCount>
    <SysCallCount>10</SysCallCount>
    <SamplingCounter Name="" ReloadValue="00000000000f4240" DisplayName="" />
    <RelocateBinaries>false</RelocateBinaries>
    <HardwareCounters EnableHWCounters="false" />
    <EtwSettings />
    <PdhSettings>
      <PdhCountersEnabled>false</PdhCountersEnabled>
      <PdhCountersRate>500</PdhCountersRate>
      <PdhCounters>
        <PdhCounter>\Arbeitsspeicher\Seiten/s</PdhCounter>
        <PdhCounter>\Physikalischer Datentr&amp;amp;amp;amp;amp;#228;ger(_Total)\Durchschnittl. Warteschlangenl&amp;amp;amp;amp;amp;#228;nge des Datentr&amp;amp;amp;amp;amp;#228;gers</PdhCounter>
        <PdhCounter>\Prozessor(_Total)\Prozessorzeit (%)</PdhCounter>
      </PdhCounters>
    </PdhSettings>
  </Options>
  <ExcludeSmallFuncs>true</ExcludeSmallFuncs>
  <InteractionProfilingEnabled>false</InteractionProfilingEnabled>
  <JScriptProfilingEnabled>false</JScriptProfilingEnabled>
  <PreinstrumentEvent>
    <InstrEventExclude>false</InstrEventExclude>
  </PreinstrumentEvent>
  <PostinstrumentEvent>
    <InstrEventExclude>false</InstrEventExclude>
  </PostinstrumentEvent>
  <Binaries>
    <ProjBinary>
      <Path>WCFServices\obj\Debug\WCFServices.dll</Path>
      <ArgumentTimestamp>01/01/0001 00:00:00</ArgumentTimestamp>
      <Instrument>true</Instrument>
      <Sample>true</Sample>
      <ExternalWebsite>false</ExternalWebsite>
      <InteractionProfilingEnabled>false</InteractionProfilingEnabled>
      <IsLocalJavascript>false</IsLocalJavascript>
      <IsWindowsStoreApp>false</IsWindowsStoreApp>
      <IsWWA>false</IsWWA>
      <LaunchProject>false</LaunchProject>
      <OverrideProjectSettings>true</OverrideProjectSettings>
      <LaunchMethod>Executable</LaunchMethod>
      <ExecutablePath>C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\WcfSvcHost.exe</ExecutablePath>
      <StartupDirectory>WCFServices\bin\Debug\</StartupDirectory>
      <Arguments>/service:WCFServices.dll /config:WCFServices.dll.config</Arguments>
      <NetAppHost>IIS</NetAppHost>
      <NetBrowser>InternetExplorer</NetBrowser>
      <ExcludeSmallFuncs>true</ExcludeSmallFuncs>
      <JScriptProfilingEnabled>false</JScriptProfilingEnabled>
      <PreinstrumentEvent>
        <InstrEventExclude>false</InstrEventExclude>
      </PreinstrumentEvent>
      <PostinstrumentEvent>
        <InstrEventExclude>false</InstrEventExclude>
      </PostinstrumentEvent>
      <ProjRef>{582C5667-EF99-4934-BD8C-938E75803D39}|WCFServices\WCFServices.csproj</ProjRef>
      <ProjPath>WCFServices\WCFServices.csproj</ProjPath>
      <ProjName>WCFServices</ProjName>
    </ProjBinary>
  </Binaries>
  <Reports>
    <Report>
      <Path>WcfSvcHost160926.vsp</Path>
    </Report>
    <Report>
      <Path>WcfSvcHost160927.vsp</Path>
    </Report>
  </Reports>
  <Launches>
    <ProjBinary>
      <Path>:PB:{582C5667-EF99-4934-BD8C-938E75803D39}|WCFServices\WCFServices.csproj</Path>
    </ProjBinary>
  </Launches>
</VSPerformanceSession>


So, this is it. Now you should be able to find your performance bottleneck in your WCF Code!