Home/ Questions/Q 764685
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T16:46:05+00:00

I know similar questions have been asked before. I am starting with a set

  • 0

I know similar questions have been asked before.

I am starting with a set of xsd-generated data objects (plus the db model is there) and need to persist these almost 1:1 to a single SQL Server database. The number of entities is small (10), and the logic required for the db insert/update/delete (mostly upserts) is thin (albeit there is some).

I am wondering which approach is best?

  1. no ORM with SQL Server stored procs, probably generated using T4
    or something like codeSmith
  2. Entity Fx, generate entities from Db, and manually map the xsd
    entities to EFx entities at runtime
  3. Entity Fx, generate edmx file from DB, then use the POCO approach
    and directly persist the xsd-generated entities (after handcoding
    the ObjectContext derived class I suppose)
  4. code-only EFx approach (looks like one of the most idiotic ideas I have ever seen to me)
  5. anything else?

I am especially keen in terms of maintenance – what happens if a property is added to the XSD-generated entities, how much effort does each approach take.

I would be tempted to go with 1, since the logic is slim and there are no complex mappings (m:n). But it would be possible the Data model will evolve to a more complex domain model, and we don’t want to reimplement anything then.

How bad does each of the EFx approaches hurt in terms of run-time performance?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Your decision in this case should be informed largely by the future direction of your application.

    You should consider Option 3 primarily if you do not want your Entities to have any dependency on the Entity Framework assembly (System.Data.Entity). If you think you might want to distribute or share your Entity/DAL/BL layer as an independent assembly with another application, consider option 3. This will allow you to keep your Entities separated from your persistence implementation. If, however, you don’t expect to have multiple persistence implementations and don’t care about the dependency on the EF assemblies, options 1 or 2 will work just fine.

    On a side note, given the limited persistence logic required, be sure to look into compiled queries in Entity Framework for a big performance improvement.

    • 0