2

I'm currently assign to a project where their legacy system is designed in a horrible way and it's been too much focus on database design. I trying to put together a new design where the customer can migrate the legacy system bit by bit.

They are currently using EF 4.1 BUT not code first approach with entity descriptive/mapping is located in an edmx file. They do Reverse engineering everytime to want to extend the model (First make changes in database, then reflect them upwards to Model layer through a custom tool).

What I would like to know, if anyone has used BOTH edmx and code first approach with mapping classes. And is there drawbacks to know about?

Magnus Backeus
  • 2,242
  • 17
  • 24

2 Answers2

3

You can use EDMX and code mapping together only if you have separate context type for each approach (you cannot mix approaches in single context type). That is probably the biggest disadvantage because it leads to more complex code and maintenance.

For example if you need to have some entity in both contexts types to use it with both new and legacy code you must maintain its mapping twice. You must also be very careful about not duplicating entity class itself = your code first must use class generated by custom tool for EDMX but this will not be possible if they are not using POCOs in current solution.

Another problem will be database integrity. If you will need to save changes to both context types in single transaction you will have to use TransactionScope and distributed transaction = MSDTC (each context instance will handle its own database connection).

If you are sure that whole system will be migrated you can probably think about using code first instead of EDMX (but be aware that code first mapping and DbContext generally offers more limited feature set). If you are not sure that you will be able to complete whole migration don't even think about using code first because leaving system in the state where half uses code first and half EDMX will make everything only worse and much more horrible.

Being sure is little bit theoretical because in SW development the only think you can be sure about is that requirements / situation will change. It means that migration should be very carefully considered.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Good answer. Thanks. I do realize the problems with transactions but Migration will probably be done with Aggregate root by Aggregate root. Beginning from the outer roots with less dependencies and working towards the center roots with complex dependencies. We'll do a test spike first to see how it goes. – Magnus Backeus Dec 06 '11 at 09:21
0

I also was struck with this problem. What I found was that you can model the database and "generate the database from the model" in a "Ado.NET Entity model Project".

But you can not create stored procedures in that project, What only you can do is you can import the stored procedures from the server.

But if you do not want to create stored procedures on the server, you can create another project on VS, "SQl CLR Database Project" and you can code your stored procedures and tigers in that project and deploy them to the server.

then you can again import these stored procedures from the "Ado.NET Entity model Project" by "Update Model From Database".

Like wise you can develop your server project using both approaches(Code first and Model first)

Hope this will add something more :)

diyoda_
  • 5,274
  • 8
  • 57
  • 89