Ok so I have my roots defined. Entities inside a root are allowed references to other entities inside the same root, but not outside. There they can only have the identity or the related entity. This is all great.
But, I'm using EF5 and navigation properties are getting in the way. I really want to only define navigation properties where entities are inside the aggregate. But how can I apply some referential integrity where related entities are in different aggregates? Is the only option to add FKs manually using migrations?
And again, but... this is going to cause a bit of a problem because I want to be able to have ReadOnlyRepositories for fetching aggregated data from all over the place. I don't want to get into CQRS as there is too much of a leap there I feel. Am I stuck needing a second bounded context with a new set (or maybe derived set) of entities with extra navigation properties defined? All so i can write queries that pull data from more than one root?
Needing referential integrity usually indicates a deeper issue. Why do you need the entity identifier to exist in both tables? What is being held consistent that way? And why isn't that modeled explicitly? These questions are not as important as the answer to them. Also realize that by just using other technology over the same db schema (and proper indexes) many of your problems could go away. Who knows, you just might be doing CQRS at that point in time.
Related
Is it possible to define navigation properties between Views in EF with code first? Please, note that I do not need any tool generating any code for me. I would like to know whether or not this can get done and the logic behind this.
Suppose you have a project in which you will only work with views. No data will be created, updated or deleted (at least by you). All you need to do is queries and all you have are views.
Suppose now a second scenario in which you can also have tables, but your purpose is only to visualize data (you will treat them as views). However, there is not always a foreign key referencing the primary key of the parent table in relationships.
My question is: Can I define navigation properties in these scenarios? Or do I have to relay on joins only?
Thanks!
I'm working on this myself. Everything I'm reading indicates you have to manually edit the .edmx files so that the views are considered tables and manually add the nativation properties yourself. Downside is if you resync against the database you have to repeat the process all over again.
Re:
https://social.msdn.microsoft.com/Forums/en-US/dcbdfe52-6ba7-4e75-94aa-51c88b57635c/adding-navigation-property-to-a-view?forum=adodotnetentityframework
Is there a way to combine code-first and database-first in the same context? We are running into massive development-time performance problems when editing the EDMX file (it takes 1.5 minutes to save). I've moved our non-insert/update/delete UDFs/stored procs to some custom T4 templates that automatically generate model-first code, but I can't seem to get OnModelCreating to be called when EDMX is involved.
Other things we've considered, but won't work for one reason or another:
We can't (reasonably) separate our code to multiple contexts as there is a lot of overlap in our entity relationships. It also seems like quite a people who have gone this route regret it.
We tried having 2 different contexts, but there are quite a few joins between Entities & UDFs. This may be our last hope, but I'd REALLY like to avoid it.
We can't switch to Dapper since we have unfortunately made heavy use of IQueryable.
We tried to go completely to Code-First, but there are features that we are using in EDMX that aren't supported (mostly related to insert/update/delete stored procedure mapping).
Take a look at the following link. I answered another question in a similar fashion:
How to use Repository pattern using Database first approach in entity framework
As I mentioned in that post, I would personally try to switch to a Code First approach and get rid of the EDMX files as it is already deprecated and most importantly, the maintenance effort is considerable and much more complex compared with the Code First approach.
It is not that hard switching to Code First from a Model First approach. Some steps and images down below:
Display all files at the project level and expand the EDMX file. You will notice that the EDMX file has a .TT file which will have several files nested, the Model Context and POCO clases between them as .cs or .vb classes (depending on the language you are using). See image down below:
Unload the project, right click and then edit.
See the image below, notice the dependencies between the context and the TT file
Remove the dependencies, the xml element should look like the image below:
Repeat the procedure for the Model classes (The ones with the model definition)
Reload your project, remove the EDMX file(s)
You will probably need to do some tweeks and update names/references.
I did this a few times in the past and it worked flawlessly on production. You can also look for tools that do this conversion for you.
This might be a good opportunity for you to rethink the architecture as well.
BTW: Bullet point 4 shouldn't be a show stopper for you. You can map/use Stored Procedures via EF. Look at the following link:
How to call Stored Procedure in Entity Framework 6 (Code-First)?
It also seems like quite a people who have gone this route [multiple contexts] regret it.
I'm not one of them.
Your core problem is a context that gets too large. So break it up. I know that inevitably there will be entities that should be shared among several contexts, which may give rise to duplicate class names. An easy way to solve this is to rename the classes into their context-specific names.
For example, I have an ApplicationUser table (who hasn't) that maps to a class with the same name in the main context, but to a class AuthorizationUser in my AuthorizationContext, or ReportingUser in a ReportingContext. This isn't a problem at all. Most use cases revolve around one context type anyway, so it's impossible to get confused.
I even have specialized contexts that work on the same data as other contexts, but in a more economical way. For example, a context that doesn't map to calculated columns in the database, so there are no reads after inserts and updates (apart from identity values).
So I'd recommend to go for it, because ...
Is there a way to combine code-first and database-first in the same context?
No, there isn't. Both approaches have different ways of building the DbModel (containing the store model, the class model, and the mappings between both). In a generated DbContext you even see that an UnintentionalCodeFirstException is thrown, to drive home that you're not supposed to use that method.
mostly related to insert/update/delete stored procedure mapping
As said in another answer, mapping CUD actions to stored procedures is supported in EF6 code-first.
I got here from a link in your comment on a different question, where you asked:
you mentioned that code-first & database-first is "technically possible" could you explain how to accomplish that?
First, the context of the other question was completely different. The OP there was asking if it was possible to use both database-first and code-first methodologies in the same project, but importantly, not necessarily the same context. My saying that it was "technically possible" applies to the former, not the latter. There is absolutely no way to utilize both code-first and database-first in the same context. Actually, to be a bit more specific, let's say there's no way to utilize an existing database and also migrate that same database with new entities.
The terminology gets a bit confused here due to some unfortunate naming by Microsoft when EF was being developed. Originally, you had just Model-first and Database-first. Both utilized EDMX. The only difference was that Model-first would let you design your entities and create a database from that, while Database-first took an existing database and created entities from that.
With EF 4.1, Code-first was introduced, which discarded EDMX entirely and let you work with POCOs (plain old class objects). However, despite the name, Code-first can and always has been able to work with an existing database or create a new one. Code-first, then is really Model-first and Database-first, combined, minus the horrid EDMX. Recently, the EF team has finally taken it a step further and deprecated EDMX entirely, including both the Model-first and Database-first methodologies. It is not recommended to continue to use either one at this point, and you can expect EDMX support to be dropped entirely in future versions of Visual Studio.
With all that said, let's go with the facts. You cannot both have an existing database and a EF-managed database in a single context. You would at least need two: one for your existing tables and one for those managed by EF. More to the point, these two contexts must reference different databases. If there are any existing tables in an EF-managed database, EF will attempt to remove them. Long and short, you have to segregate your EF-managed stuff from your externally managed stuff, which means you can't create foreign keys between entities in one context and another.
Your only real option here is to just do everything "database-first". In other words, you'll have to just treat your database as existing and manually create new tables, alter columns, etc. without relying on EF migrations at all. In this regard, you should also go ahead and dump the EDMX. Generate all your entities as POCOs and simply disable the database initializer in your context. In other words, Code-first with an existing database. I have additional information, if you need it.
Thank you to everyone for the well thought out and thorough answers.
Many of these other answers assume that the stored procedure mappings in EF Code-First work the same, but they do not. I'm a bit fuzzy on this as it's been about 6 months since I looked at it, but I believe as of EF 6.3 code first stored procedures require that you pass every column from your entity to your insert/update stored procedure and that you only pass the key column(s) to your delete procedure. There isn't an option to pick and choose which columns you can pass. We have a requirement to maintain who deleted a record so we have to pass some additional information besides just a simple key.
That being said, what I ended up doing was using a T4 template to automatically generate my EDMX/Context/Model files from the database (with some additional meta-data). This took our developer time experience down from 1.5 minutes to about 5 seconds.
My hope is EF stored procedure mappings will be improved to achieve parody with EDMX and I can then just code-generate the Code-First mappings and remove the EDMX generation completely.
I'm trying to implement EF TPH using the "Database First" with the help of the following document from Microsoft,
http://msdn.microsoft.com/en-us/data/jj618292.aspx
I do understand how this works but it sounds a little naive the way it's done or I'm missing something which I would like someone to enlighten me on this.
To my understanding, the whole point of implementing a database first approach is when you have a pre-exisiting database or if you prefer to do your work first hand on your database and work your way up, however, this document suggests that the inheriting tables (Student, Instructor) are meant to be created at the EF design area using a field on the base class which they call a "Discriminator" field which your inherited entities end up pointing to.
However, my question is, why would you have to create these inherited table at the ER designer where you initially intended to create your table structure first hand before working your way up the entity framework and how would this change that you applied on the ER designer (adding the inherited tables) be mapped into the back-end database, and at the end of the day when I want to make a change to my database later on, where will I have to make these changes (on MS SQL or the ER designer). If I end up adding tables from the ER end, then that would pretty much defeat the purpose of the "Database First" methodology, because I basically ended up using the procedures in the "Model First" approach which doesn't make sense at all.
Your help in clearing this up would be much appreciated.
PLEASE NOTE: I would rather have everything done at my database and rather not use the "Model First" approach. I'm interested to implement the TPH and be able to make any changes directly to my database and have those changes mapped into my EF sublayer (not the other way around).
Many Thanks
I don't see how EF could ever infer inheritance for you. Maybe it would be possible to have it triggered it by a field explicitly named "Discriminator" in a table, but what if you want a different name for the discriminator? And then, what should be the names of the derived classes? EF has no clue. The names are nowhere in the data model.
Still, it is database first. But EF just creates a first draft of the mapping. Nearly always you need to make modifications to the conceptual model (the model you see in the edmx), like renaming properties or classes, renaming/adding/removing associations. Or applying inheritance. When you update the the model from the database it may be necessary to apply some more manual changes. For instance, with TPH inheritance you may have to decide in which class to put a new field.
Maybe you are a bit side tracked by the idea that you "have to create these inherited tables at the ER designer". You define classes that map to one and the same table.
If you have used the Entity Framework then you know the EDMX is cool. You also know it can become HUGE and almost unmanageable.
When it gets large, it is tempting to create a second EDMX or third - even one for each Schema in your database (just as an example).
Such a seperation would help with organization of your EDMX, but it could seperate the context of entities in the same namespace.
Moreover, seperate EDMX files can create a situation where a JOIN operation across EDMX files results in excessive, redundant database communication.
But, the fact remains, the larger the EDMX, the more difficult it is to use. The more difficult it is to ensure it is correct. The easier it is to break.
Do you break your EDMX files apart? Do you have a rule of thumb for when to it?
One example for the need to split your EDMX would be
if you have a group of entities that are used in more than one project,
while others are project-specific and you are willing to forsake having navigation properties between the parts (and remain with only exposed FKs).
You can automatically merge the EDMXs into one if you want to maintain the separately, but open up a context to them all and query as one. This requires that they share the same namespace.
We've only gone as far as needing to use two separate EDMX in a single solution. This separation occurred for us with an EDMX for domain specific model entities and another for those more common across all of our solutions (Payment as an example). Logically you could say this for us was at the db schema level although that wasn't the hard rule of the separation.
Whilst we didn't have a requirement for joins across them we did need transactions. We accomplished this with a reusable UnitOfWorkContainer that would wrap the EF contexts within a TransactionScope. The contexts would be injected through DI into the container and we would only use the TransactionScope if there was more than one context held in the container.
The container itself implemented our IUnitOfWork interface so it was dead easy to plug into the existing codebase.
I thought I'll post this to the community. I am using coredata, and have two entities. Both entities have a hierarchical relationship. I am noticing quite a lot of duplicated functionality now, and am wondering if I should re-structure to have a base Entity which is abstract (HierarchicalObject), and make my entities inherit from them.
So the question is are there some limitations of this inheritance that I should take into account? Reading some of the posts out there, I see a few trade-offs, let me know if my assumptions are correct.
(Good) clean up structure, keep the HierarchicalObject functionality in one spot.
(Ok) With inheritance, both objects now end up in the same sqlite table (I am using Sqlite as the backend). So if the number of objects grow, search/sorting could take longer? Not sure if this is a huge deal, as the number of objects in my case should stay pretty static.
(not so good) With inheritance, the relationship could get more complicated? (http://www.cocoadev.com/index.pl?CoreDataInheritanceIssues)
Are there other things to take into account?
Thanks for your comments.
I think it's a mistake to draw to close a parallel between entities and classes. While very similar they do have some important differences.
The most important difference is that entities don't have code like a class would so when you have entities with duplicate attributes, your not adding a lot of extra coding and potential for introducing bugs.
A lot of people believe that class inheritance must parallel entity inheritance. It does not. As a long as a class descends from NSManagedObject and responds to the right key-value messages for the entity it represents, the class can have many merry adventures in it's inheritance that are not reflected in the entities inheritance. E.g. It's fairly common to create a custom base class right below NSManagedObject and the have all the subsequent managed object subclasses inherit from that regardless of their entities.
I think the only time that entity inheritance is absolutely required is when you need different entities to show up in the same relationship. E.g:
Owner{
vehical<-->Vehical.owner
}
Vehical(abstract){
owner<-->Owner.vehical
}
Motocycle:Vehical{
}
Car:Vehical{
}
Now the Owner.vehical can hold either a Motocycle object or a Car object. Note that the managed object class inheritance for Motocycle and Car don't have to be same. You could have something like Motocycle:TwoWheeled:NSManagedObject and Car:FourWheeled:NSManagedObject and everything would work fine.
In the end, entities are just instructions to context to tell it how the object graph fits together. As long as your entity arrangement makes that happen, you have a lot flexibility in the design details, quite a bit more than you would have in an analogous situation with classes.
I thought it would be useful to mention that the Notes app on iOS 10 uses inheritance in its Core Data model. They use a base entity SyncingObject, that has 7 sub-entities including Note and Folder. And as you mentioned all of these are stored in the same SQLite table which has a whopping 106 columns, and since are shared among all entities most are NULL. They also implemented the folder-notes one-to-many relation as a many-to-many which creates a pivot table, which might be a work-around for an inheritance problem.
There are a couple of advantages to using entity inheritance that likely outweigh these storage limitations. For example, a unique constraint can be unique across entities. And a fetch request for a parent entity can return multiple child entities making UI that uses fetched results controller simpler, e.g. grouping by accounts or folders in a sidebar. Notes uses this to show an "All Notes" row above the Folder rows which is actually backed by an Account.
I have had issues in the past with data migration of models that had inheritance - you may want to experiment with that and see if you can get it to work.
As you noted also, all objects go in one table.
However, as Core Data is managing an object graph, it is really nice to keep the structure the way you would naturally have it just modeling objects - which includes inheritance. There's a lot to be said for keeping the model sane so that you have to do less work in maintaining code.
I have personally used a fairly complex CD model with inheritance in one of my own apps, and it has worked out OK (apart from as I said having issues with data migration, but that has been so flakey for me in general I do not rely on that working any longer).