I'm using 'EF Designer from database' approach. In my generated models I have a few ICollections that I don't really need. Can I remove those ICollections without breaking stuff?
Depending on what they are actually being used for you may be able to remove them without breaking anything, if you know what you are doing.
The problem is, as it is with any auto generated code, that if you make schema changes down the road and need to regenerate your model whatever you have removed will be added back.
Therefore, the recommended approach is to remove the collections that you don't need from your model in the model designer and generate the model without those collections.
Related
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.
I have to create a new project and (as usual) is with an existing SQL Server database.
I used to use EF Code First connecting with my database, opening my EDMX model designer and then right click --> Add Code Generation Item. (http://weblogs.asp.net/jgalloway/archive/2011/02/24/generating-ef-code-first-model-classes-from-an-existing-database.aspx) Easy.
But now I've discovered there's something called EF Power Tools that allows me to do Reverse Engineer Code First (cool name!) and get the same (http://msdn.microsoft.com/en-us/data/jj200620)
Do you know the difference between the two options? Which one is better?
Thanks in advance.
(Sorry if this question was previously asked but I didn't find it.)
The difference is that the edmx approach is not code first, but database first with DbContext API. You will always use the database as the source of model changes.
EF Power Tools produce a truly code first model with DbContext: from then on you will change the class model first and modify the database accordingly (e.g. by EF migrations).
Neither is "better". DbContext API is easier to work with than ObjectContext, but both approaches use the former. It's up to you to choose whether you want to work database first or code first. It's a matter of personal preference and it may depend on who maintains the database structure. With database first it is easier to respond to changes someone else imposes on the database structure.
As far as workflow goes for database first, adding to what #Gert-Arnold said:
With database first it is easier to respond to changes someone else imposes on the database structure.
If someone else is managing the database changes, I'm finding it far easier to use the EF Designer. You get an updated database, then just right-click in the EF Designer and update the model from the database. You can use source control to easily view what has changed.
Also, if you only need a subset of tables from the database, reverse engineering causes alot of work having to go back and remove classes and properties from the context.
I found re-reverse engineering via code-first to an existing database to be just too much of a pain trying to figure out what changed and how I needed to update code that used the context.
So When I use the EF wizard right now and choose a view, it creates entities for every column in the view. How can I select entity generation for a specific few columns? I don't need all of them. Also, the DB schema changes often. Anything I can do to make sure it doesn't break my app?
You asked two questions, so this will be a two-part answer.
[Answer 1] There is no way to choose specific columns when generating the model via the wizard. However, once the model is generated, deleting a property will remove it (and its mapping) from the model. (Note that non-nullable columns will need to be surfaced as properties or you will get errors).
[Answer 2] In terms of responding to a schema which changes often, your best bet will to make sure you understand what is going on underneath your model. The EDMX contains 3 sections:
The "CSDL" - this is the "conceptual model" where your entity definitions are stored.
The "SSDL" - this is the "storage model" which keeps track of the state of your database.
The "MSDL" - this defines the mapping between the two.
When your DB schema changes and you run the "update model from database" wizard, your CSDL and SSDL may get out of sync. This is because the SSDL gets updated with the changes, but the CSDL will not (unless you are adding something new). Now, for the most part, this is a good thing, because it will not blow away any changes you've made, so your model will still work with your application logic. But you may see errors due to the changes in the SSDL.
There are a few ways to fix this:
If the changes to the database were relatively simple (added columns, renamed tables, etc) you might be able to simply redefine your mappings (using the "mapping details" window available in an entity's context menu). This does require some manual work. For instance, if new columns are showing up in the SSDL you'll need to add the corresponding properties yourself. You may even need to re-map an entire entity if your tables get renamed or too many mappings get dropped.
You can remove affected entities from the model and re-add them using the "update" wizard. This will blow-away any customizations you had made, and might cause some of your application logic to break. But if you are happier responding to database changes by updating your application's code than by mucking around with your entity mappings, this could be another option.
You can edit the XML manually. The designer isn't perfect for every situation, so if worse comes to worst you can always use the XML editor.
Hope that helps! There may not be a perfect solution, but it should get you most of the way there.
I've been scratching my head over this for over a week now and haven't gotten anywhere :( We have an existing legacy DB that I'm trying to model my entities against. The tables are extremely bloated and we do not have enough bandwidth to create new, optimized tables. So I'm having to work with what we already have. However, I do not want to use all the redundant columns that are exposed by the DB. My initial plan was to use Views in my Model but that is looking to be equally hairy with very little documentation around.
Now, what would be the best way to go about creating a Model with just a select few columns? All I need is a bunch of read-only entities; so if there is a way to ignore non-nullable columns from the schema, I'd be all set. I was planning on making use of POCOs else I'd have to create my own mappings I reckon.
UPDATE: By POCOs, I mean I'd like to use the ADO.NET POCO Entity Generator.
What about creating views in the DB, and only importing the views into the model?
Well, if you need only a bunch of entities and if they won't change a lot during time, than I would just pick the tables you need, generate the entities with the normal wizard and all collumns, and than delete all not needed collumns manually in the model designer.
add the table to your EF, and just delete the properties you don't want. it just won't map those DB fields.
I have a database that I wish to build an EF model from, however I do not want to include certain columns from the database as the columns concerned are maintained exclusively on the server and should not be manipulated by any application.
Both of the columns are DateTime (if this makes any difference), one of the columns is nullable and is maintained by a trigger on updates and the other is not nullable and set using a default value in the table definition.
I guess I am looking for something like the "Server Generated" option in Linq2Sql; but I cannot find such an option.
Can anybody tell me how to work around this?
Caveat:
I have been trying to introduce business object modelling at my place of work for some years and it has always been rejected because of the amount of additional code that has to be hand-cranked. EF is currently being seen as a viable solution because of the designer and code generation therefore any option that involves hand-cranking the XML will only turn the rest of my colleagues away from EF. I am therefore looking for something that can be done either using the designer or using code.
EDIT:
I guess that what I am looking for here is either...
(a) a way to create the model without EF referencing the columns in the store (ssdl) and therefore not looking to manipulate it in any way
(b) a way to programatically set the "StoreGeneratedPattern" attribute against the property when I create the ObjectContext (the easy answer is to manually manipulate this in the .ssdl, but this would then be overwritten if I refreshed the model from the database and I cannot go down the route where the .csdl, .msl & .ssdl are hand-cranked).
Can you do this with the Entity Framework? Yes; it's easy. Can you do this with the Entity Framework designer? Unfortunately, that is much harder.
The problem you're having is that the column exists in the storage schema (SSDL) in your EDMX. Removing the column with the GUI designer simply removes it from the client schema, not the mapping or the storage schema. However, it's simple enough to go into the EDMX and remove it. Having done that, you can also remove it from the mapping in the client schema portions of the EDMX, and the entity framework will longer complain that it is unmapped.
Problem solved, right?
Well, no. When you use the GUI designer to update the EDMX from the database, the storage schema is thrown away and re-generated. So your column will come back. As far as I know, there is no way to tell the GUI designer to never map a particular column. So you will have to re-do this every time you update with the GUI designer. Fortunately, the EDMX is XML, so you can do this with a XML transform, LINQ, or the XML tool of your choice.
Can you not create a view with the columns you need and import it through entity function wizard and map it to your entities?
You could modify the text template to ignore these columns when generating your entity classes. For example if you added "IGNORE" to the documentation summary, you could modify the template to ignore them by replacing;
Dim simpleProperties as IEnumerable(Of EdmProperty) = typeMapper.GetSimpleProperties(entity)
with;
Dim simpleProperties as IEnumerable(Of EdmProperty) = typeMapper.GetSimpleProperties(entity).Where(Function(p) p.Documentation is nothing orelse p.Documentation.Summary.IndexOf("IGNORE")<0)
Right click on the field in the graphical representation and choose delete. Ive found that sometimes you will get errors when you make a lot of changes to the modeling at once and start to lose track of your changes. Your best bet might be to rebuild the EF generated model.
Keep in mind that when you "update from the database", that old fields on the generated models will not be removed, you will have to remove them manually. For example if you renamed DateField1 to DateField2 in your database, and then you "Update Model from Database", you will now see both DateField1 and DateField2 on the resultant model. This can be a cause of errors.
Do you not want the column to appear in the model at all?
Try selecting the column in the Designer view and hitting the delete key.
Edit
You could make the setter for the property private. Then your app won't be able to modify the value.
Timestamp is a different data type than DateTime. Timestamp seems to be recognized as an attribute the engine manages, much like an identity attribute. You can't "update" a timestamp attribute. Hence, the EDM can manage it correctly (just as it does an identity).
In EDMX designer, select the property and set StoreGeneratedPattern to Computed.