Tag Archives: entity framework

Code First Dynamics CRM?

A friend and former co-worker of mine, Jake Ginnivan forwarded a thread to me started by Darrell Tunnell to the DbUp mailing list. DbUp is a .NET API for building database migration tooling for applications by sequentially applying update scripts to a database, and keeping track of which scripts have been applied.

Darrell’s thread mentioned that he was working at a derivative work which could be used to apply changes to Dynamics CRM, he has called his tool CrmUp. For those of you who haven’t used Dynamics CRM before, out of the box it provides a way for businesses to manage sales, service and marketing processes.

Dynamics CRM is interesting from a development perspective because it is all built upon a customisable foundation where you can build your own custom business entities, relate them together and build processes that flow across the top of them complete with dashboarding and reporting. For some classes of problems it is a very productive development environment.

The product bundles customisations together into things called “Solutions” which contain the definition of all the customisations to be applied and this allows developers to ship grouped customisations to target environments. CrmUp is useful because it allows Dynamics CRM to be treated like an application dependency that can be upgraded to a baseline version.

Darrell’s work has got me thinking about what I would want from a developer orientated framework for managing customisations to Dynamics CRM. If we look at databases generally there are three broad approaches:

  1. Model/Tooling Driven Migrations (e.g. Database Projects in Visual Studio)
  2. Script Driven Migrations (e.g. *.sql scripts applied sequentially)
  3. Code Driven Migrations (e.g. EF CodeFirst)

Dynamics CRM doesn’t have a project type in CRM. The development environment is really CRM itself, from which you can export you customisations. It is these exported customisations (solution files) which are then fed into CrmUp.

Personally I am a huge fan of the way that Entity Framework Code-First migrations work. I love the fact that I can define my database entities in code, and add behaviour to them and then use the tooling to build a “migration” which takes me from one version of the database schema to the other. This leads me to wonder what a Code-First CRM framework would look like.

Dynamics CRM has various customisable elements:

  • Entities (create new, and extend existing)
  • Processes, Workflows & Workflow Activities
  • Reports
  • Dashboards
  • Views
  • Forms (for Entities)
  • Service Endpoints
  • … and many more.

This is perhaps what makes the CrmUp approach somewhat easier to get off the ground (because you are leveraging existing solution/customisation files). But in the long run a code-based way of defining the above would be incredibly useful.

For example, it would be great if I could define an entity in code:

[Entity(Name = “CustomEntity”)]
public class CustomEntityDefinition: EntityDefinition
{
public override void Retrieve(RetrieveContext context)
{
// Do whatever.
}
}
Having this entity definition as part of a deployment would result in an entity being created, but a plug-in would also be generated which would route traffic to an Azure host (in the Dynamics Online scenario) to invoke the Retrieve method whenever that entity is retrieved.

There would be additional base classes and associated attributes to describe all aspects of a CRM solution in-code, and then you could do something similar to “Enable-Migrations” from Entity Framework to create the migration scaffolding. As the code is updated you could call “Add-Migrations” and it would generate a migration between the earlier migration and the current state. It would also take into consideration publisher details/signing and versioning.

I personally think that Dynamics CRM is an awesome product, and I’ve been working with it for years, but I would really love to have a more streamlined developer experience. Hat’s off to Darrell Tunnell for his contribution. I hope that the Dynamics team looks at what he has done and also looks at how the Entity Framework project has approached the challenge.

Advertisements

CA2214 & Entity Framework

I’ve just submitted a comment to the CA2214 code analysis guidance. Posting it here just in case others come across this and wonder what they should do.

There are some circumstances where, using Microsoft’s supplied frameworks this is unavoidable. For example, lets say that I am using Entity Framework:

public class Client
{
public Client(string name, User ownedBy)
{
Name = name;
OwnedBy = ownedBy;
}
protected Client()
{
}
public string Name { get; protected set; }
public virtual User OwnedBy { get; protected set; }
}

In order for Entity Framework to lazy load the OwnedBy property it needs to be marked as virtual. However we might want to stop developers constructing the object without providing the minimum mandatory information (in this case a name string, and a User instance who owns the object). When doing this the CA2214 code analysis warning is fired. The simple solution (in theory) is to mark the Client class as sealed, however Entity framework needs a default constructor to call. The way it works is by inheriting from the Client class with a default constructor which points to the protected constructor, thus allowing it to inject the code to traverse lazy loaded properties/collections etc.

I believe that whilst the guidance provided by CA2214 is valuable, it is inappropriate to say “Do not suppress a warning from this rule” because in some cases you might need to do it by design. Given the proliferation of ORM tools which use this approach for lazy loading of properties the guidance should be updated to outline some scenarios where you might want to call a virtual member.