06:58:37 AM
3GG0EYFA8
I never put much thought into having relationships in the entities but that's just my lack of understanding. I am also trying to understand why that is so important.
Your 'old' entity generator does a great job generating the entities with no relations, pretty straight forward. It lets me check the tables I want to 'entitise' and bam! there it is. Updates to the structure are a snap too, especially if you have more than one person coding against the DB making changes to table structures. However, I was always under the assumption that the classes handle the relationships by hydrating the objects from the single entities.
The test project I mentioned is very relational. The invoice class handles the relations from the invoice header record to lineitems, items, customers, shipping addresses, etc. and all you have to do is call invoice.save() and the business classes handle all the relational saves.
Why worry about entities and their ability to handle relationships?
Thanks again!
Craig
I do... if I have the luxury of determining the DB schema (ie. no pre-existing schema) it's really nice not to have to create the DB first, but create my model and let the DB be created from the model. That's the way it should work.
If you go the other way, you're losing some of that obviously, but frankly it's pretty quick to create entities manually. FWIW, the EF Code First power tools includes a tool that will create a model from a db, but i've found it doesn't do a good job especially when linking related entities. It's the relationships that are a killer.
My old entity generator didn't create relationships - it just created tables and include fk values in the fields which you are responsible for managing in your code. EF COde first understands relationships and maps one to many and one to one relationships automatically and many to many with some effort. IOW the reason you generally don't want to use a generator is that EF Code first supports relationships in the models (like List<ChildEntity> or ChildObject) and these relationships need to come through. And that's where generators tend to suck because they often don't understand the extent of visibility resulting in models that don't work because of recursion or other invalid relationship issues.
Hand mapping is more work, but the nice thing about EF Code First is that it's really simple - no special classes, no explicit mapping all you do it declare a property and put a few attributes and you're done. So keeping things in sync is not as bad as it seems. Further now with Code Migrations you can keep track of changes your code does to the entities and automatically push the new schema to a database - haven't played with that much yet so not sure how well that works.
If you like the old approach better then using something like Rob Conery's Massive might be interesting - which is a dynamic engine for querying and returning entity data. Nothing is typed so there's no mapping - you just get dynamic objects back.
+++ Rick ---
+++ Rick ---
Hi All,
I wanted to start a new thread on EFCodeFirst comments, just the theory - not ww classes...
After readying the great response in another thread "Entity Framework Code First", I asked myself what am I missing here from a programmers perspective?
It looks to me like it should be called Entity Framework Ass Backwards.
Why would someone code there classes first, then hand create the entities to generate the DB tables?
I wanted to see what was so cool about EF Code First; however, I would take creating my tables and running the EntityGenerator any day of the week over hand writing the entities. Even if I found a generator that would generate entities from my classes and create the the tables I wouldn't trust it a bit and always plan on creating my tables by hand (or hand generated script).
The project I am working on already has the tables so all I needed to do was point the Entity Generator at it and have my entities in less than 3 seconds. Going the code first route would have taken a few hours, and even then you'd have to maintain it as opposed to just regenerating..
Is there anybody out there that actually programs the Entity Framework Code First way?
Open for discussion!
Thanks, Craig
