I shall have to pick this apart a bit and bear in mind I am not an EF expert. What you describe is very interesting and has some similarities to my endeavours.
I am using a database-first approach (I guess you are model-first). The pre-existing database has complex views that have been made updateable using instead-of triggers. (In principle they could be refined into a semi-inheritance model but
I haven't done that. Following that path would probably simplify what I have done. Thanks for the thought, I'll look at that but not just yet)
The database mapping through EF maps mostly to these updateable views. Unfortunately so far as I can tell the standard operation of EF Designer makes views read-only, unless I also provide stored functions for the CUD operations on the
It is possible to manually edit the model.edmx file to make the updateable views look like tables which are read-write (essentially the same principle as patching the edmx.sql file). I was reluctant to do that because I seem to have refix the model.edmx
file each time I update the EF entity model (which is regularly as I am working incrementally with the ultimate users, both on the database functionality and the presentation. NO is superb support to this process).
Apart from the additional complexity of defining and mapping stored procedures the DB works well with NO, with one exception that I have not found the answer to. One 'instead-of-view' has an auto identity key. The create SP returns the newly created
key to EF however the NO object -create form does not pick up this newly created key when it returns to the browser the persisted object data in the completed form so the key is '0'. If the user tries to Edit the returned object immediately, it will fail
(incorrect PK reference '0'). However if the object is re-found through the menus (by search, browse etc) all is well, the object has been correctly persisted in the database, is known fully to the EF and is now known fully to NO.
I would very much like to find the answer to that problem. It seems related to your comment about returning the @@identity which is effectively what I do through the stored procedure using the the standard MS mapping.