应用程序从EF4迁移到Dapper.net

Question

I am working on a large WPF application with Entity framework4 now client is asking to migrate application from EF4 to Dapper.net. I am not sure about feasibility & business gain of this migration task as following features of EF4 are missing in Dapper:

• Change tracking
• Lazy-loading
• Eager fetching
• Cascades
• Identity map
• Unit of work tracking

please suggest me on this or if other better micro ORM exists for WPF applications.

Answer 1

EF4 and dapper are different tools with different goals and different features. Indeed, it is pretty common to see dapper and tools like EF working side by side (sometimes even against the same object-model) - particularly when you aren't using all the things you've listed in the bullets; for example, a lot of "display" code (showing pages to the user, etc) tends to not use those things. For read-only code, it can sometimes be embarrassingly simple to switch in a dapper implementation - just write some SQL and away you go.

However! When it comes to code that does use the features you've mentioned, this is a much more fundamental change; it isn't really "migrate" so much as "re-implement". Without things like change tracking, your own code would need to be a bit clearer about what operations each process is performing. This is actually a good thing, IMO, but is not trivial to retrofit into an existing codebase. If starting from scratch (or: new tables etc in an existing model), it is generally very easy.

Personally, the approach I would take here is first to look at your key data fetch operations (especially high frequency, complex query, or large volume) - and consider whether they could be replaced with dapper-based read operations; especially if read-only. You can probably get some huge wins with minimal work. Profiling would be important, and tools like mini-profiler might help. I would not personally start ripping out an existing, working data layer for the rest of it - that seems like inventing work for the sake of it; and it will be complicated (swapping out an ORM is not a trivial thing).

I would , however, put some serious thought into updating to a more recent version of EF ;p

(oh, and if it matters: I'm the primary author and maintainer of dapper)

Answer 2

In my opinion, the crucial question is why your client want you to migrate this project to another framework.

If she wants you to perform this migration because of poor performance of some functionalities or modules then you could take Marc's approach and migrate only critical parts of your system.

In some of my company's projects we use Dapper side by side with full-blown NHibernate stuff and it really works. Especially in reporting and batch processing when you probably want to call stored procedures instead of simple CRUD operations.

If you decide to follow this path, I'd suggest you to consider using "Unit of work" pattern to enable EF and Dapper to work on same database connection (I've bloged about this matter some time ago).

Of course you have to keep in your mind technical differences like that Dapper (in opposite to "full-blown" ORMs like EF or NH) does not have concept of session and "dirty" objects modified by EF should be read by Dapper only after flushing changes to DB.