I am writing an app with a database that has a slightly unusual schema. At least I think it’s unusual, I rarely do DB stuff.
All my books tell me I should be using Entity Framework (or some other ORM) for DB access, but the examples they give are always bog standard CRUD. One table per entity, one row per object, active record etc.
My schema uses disjoint subtypes, so multiple tables per entity, and has revision history so edits actually create a new row, but only in one table (depending on the field/s edited)
Does EF cater for this kind of custom behaviour or is it geared toward conventional patterns? My understanding is that I create a schema or domain objects, and the database manipulation code is automatically generated. Can I override the default behaviour? How else could I tell EF about my custom behaviour?
I am more than willing to learn EF if it is going to make my life easier, but I don’t want to put a lot of effort into learning a framework that I am going to end up fighting to make it do what I want. If this is the case I would rather just roll my own repositories and handle the SQL myself.
The question is too abstract to be definitely answered. EF offers some advanced mapping scenarios where more tables can be mapped to single entity but it defines strict rules to achieve that. Alternatively you can map database views or custom SQL queries combining data from your tables to form your entities.
More complicated is your second requirement – it generally requires writing your own SQL / stored procedures and map it to EFs CUD operations performed on tables. This SQL code will contain part of your update rules because EF updates whole entity not only affected record. If you use mapped views or queries you must map these CUD operations to custom SQL or stored procedures because otherwise your entities will be read only.
Conclusion: It can be possible to achieve what you want but it is not simple, it requires advanced knowledge of EF and you will still write some SQL.