We've just launched www.silverwardrobe.com.
Custom theme, a few custom features (banner module and order processing changes), and integration and customization of CardSave's Payment Page.
Enjoy!
Profile: retroviz
MVP
Statistics
United Kingdom
751
4093
Friday, January 23, 2009 6:18 PM
Ben Foster
http://blogs.planetcloud.co.uk/mygreatdiscovery
http://blogs.planetcloud.co.uk/mygreatdiscovery
Hi, yes it's just temporary. Should be back up in a few hours.
Thanks
Ben
Thanks
Ben
Almost every part of nopCommerce is being re-evaluated so it's likely that the database schema will change also.
There will be an upgrade path from 1.90 for your data.
There will be an upgrade path from 1.90 for your data.
We don't plan to use MEF but will be achieving something similar with StructureMap.
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 :)