I'm trying to understand the architectural direction taken for the EF. Currently all of the entity classes are implemented as manual POCO's instead of letting the Text Templating system generate them on the fly. The default TT has been modified and the code to auto-gen the entity classes has been removed. What’s the reasoning behind not letting the entity classes be auto-generated?
I do see that you’ve used your IOC factory in various places within the entity classes but I don’t see why that is necessary when the EF can simply handle those calls for you. It appears to me that the IOC calls specifically in the entity classes are redundant and duplicate the work you would get for free from the EF auto-gen’d classes. I also know that nopCommerce stores some items in the CustomerAttributes table but again entity classes are partial and you could simply extend each class with a separate file to include the same functionality while still allowing the TT to auto-gen each class for you.
The reason I ask is because it’s a lot more overhead extending this framework with new tables and features because it’s requires me to also manually create my entity class instead of letting the TT do the heavy lifting for me automatically.
thx,
Joey
Entity Framework in nopCommerce
MVP
- 751
- 4113
- 1/24/2009
- United Kingdom
degree451 wrote:
We have made an architectural decision to use POCOs. Our domain layer should be completely persistent ignorent and not tied to a specific data access technology. This makes it much easier to test and more flexible.
In version 2.0 we will not be using the Entity Framework designer at all, we will be using Code First. There wont be any need to create tables, EF will do it for you based on your domain mapping.
You may want to read up on domain driven design.
Regarding the IOC calls inside the entities (or CODE SMELL as I like to call it), yes this is bad and we should let our ORM wire those associations up for us. This wasn't done in existing versions of nopCommerce - it will be in version 2.0. You can of course do this with your own extensions - that's what I did :)
I'm trying to understand the architectural direction taken for the EF. Currently all of the entity classes are implemented as manual POCO's instead of letting the Text Templating system generate them on the fly. The default TT has been modified and the code to auto-gen the entity classes has been removed. What’s the reasoning behind not letting the entity classes be auto-generated?
I do see that you’ve used your IOC factory in various places within the entity classes but I don’t see why that is necessary when the EF can simply handle those calls for you. It appears to me that the IOC calls specifically in the entity classes are redundant and duplicate the work you would get for free from the EF auto-gen’d classes. I also know that nopCommerce stores some items in the CustomerAttributes table but again entity classes are partial and you could simply extend each class with a separate file to include the same functionality while still allowing the TT to auto-gen each class for you.
The reason I ask is because it’s a lot more overhead extending this framework with new tables and features because it’s requires me to also manually create my entity class instead of letting the TT do the heavy lifting for me automatically.
thx,
Joey
I do see that you’ve used your IOC factory in various places within the entity classes but I don’t see why that is necessary when the EF can simply handle those calls for you. It appears to me that the IOC calls specifically in the entity classes are redundant and duplicate the work you would get for free from the EF auto-gen’d classes. I also know that nopCommerce stores some items in the CustomerAttributes table but again entity classes are partial and you could simply extend each class with a separate file to include the same functionality while still allowing the TT to auto-gen each class for you.
The reason I ask is because it’s a lot more overhead extending this framework with new tables and features because it’s requires me to also manually create my entity class instead of letting the TT do the heavy lifting for me automatically.
thx,
Joey
We have made an architectural decision to use POCOs. Our domain layer should be completely persistent ignorent and not tied to a specific data access technology. This makes it much easier to test and more flexible.
In version 2.0 we will not be using the Entity Framework designer at all, we will be using Code First. There wont be any need to create tables, EF will do it for you based on your domain mapping.
You may want to read up on domain driven design.
Regarding the IOC calls inside the entities (or CODE SMELL as I like to call it), yes this is bad and we should let our ORM wire those associations up for us. This wasn't done in existing versions of nopCommerce - it will be in version 2.0. You can of course do this with your own extensions - that's what I did :)
- 255
- 1395
- 5/25/2010
- Australia
just wondering I'm very used to the diagram-based approach to ef.. where in nop are the classes setup that are generating the db tables.. im having an issue with a missing column and would love to work out how it's all hooked together.. i can see the viewmodel mappings but not really sure where to go looking for the codefirst stuff..