0

Let's say you have a software solution that has a data layer that accesses a SQL server. It can do this either directly and also over a HTTP connection. In both cases Datasets are used.

Now when migrating away from Datasets to a more modern technical solutions of course using an ORM framework might be the natural choice. However as there was support for accessing the database over HTTP before if you want to do a similar thing with the ORM framework it means you are working with detached entities.

So I am looking for strategies to tackle the migration. I could either use ORM with detached entities and do change tracking by myself.

A first attempt using TrackableEntities was rather a disaster (in this case we tried EF 6).

A second attempt looks quite promising to me when using an object diffing framework as for example ObjectDiffPatch in combination with NHibernate. This would mean that when wanting to save an object a diff is created with the help of a previous snapshot. This diff is send over HTTP to the database server where the diff is applied to the entity in the NHibernate session. I learned you cannot send the NHibernate entity directly but instead should use a separate DTO. Also these articles (Code First is bad for Domain, Don't Use ORM Entities To Model The Domain) suggest that I should anyway have a separation between my domain models and persistence models (regarding this articles, is this just the opinion of that author or a general best practice?). The drawback of this means having multiple class definition (maybe some stuff can be auto-generated?). But conceptually diffing seems to work in my prototypes very well.

Another option seems to be to use CQRS and change object always with commands. So you can also easily send command over HTTP.

Is it that CQRS can be seen as the logical follow-up solution as ORM framework don't provide something like detached entities straight away? Some have suggested to use a task based messaging system (see Tasks, Messages, & Transactions – the holy trinity) which looks very similar to CQRS. Is this how CQRS evolved as a mainstream solution to the detached entity problem?

I read that handling detached entities is a messy adventure and some people call it an anti-pattern (the stripper pattern). Currently I think that CQRS is what people have come up with as a solution to the problem. Is this true?

Can you please also provide some thoughts about the idea of working with diffing to solve the detached entity problem. Maybe you know already a scenario where something like this has been used.

  • Modern ORMs handle this for you automatically, so I don't understand what the problem is. – Robert Harvey Jul 19 '16 at 15:16
  • @RobertHarvey Which ORM does support detached entities? Or what automated alternative do they provide? – Sjoerd222888 Jul 19 '16 at 15:18
  • 1
    What problem are you trying to solve? Patterns are solutions to well-known problems, so in order to select the correct pattern, you must first understand the problem. Detached entities are not the problem; they are the solution (if they, in fact, solve whatever actual problem you have). – Robert Harvey Jul 19 '16 at 15:51
  • Okay, so currently you're sending Datasets over the wire to a client, and then getting an updated Dataset back which you then save with a TableAdapter? You will need to modify this pattern to sending just plain objects over the wire, and when you get the updated objects back, you'll need to lean on the ORM framework of your choice to persist the updates. The most reliable way to do this is to load the unmodified entity from the DB with your ORM and apply the updates manually. (unchanged.Name = received.Name, etc.). – Spivonious Jul 26 '16 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.