It's not clear to me if this change is going to allow for adding new entities and relate the new entities to existing entities in a plugin.
For example, I currently have a custom version of nopC where Products have one or more Suppliers. There's a new Supplier entity, and a new ProductSupplier entity (both in namespace Nop.Core.Domain.Catalog), and the Product entity was extended to include a collection of ProductSupplier. (All similar to how a product can have one or more manufacturers). Can all this now be done in a plugin?
(P.S. Why do plugins with data access require their own custom db context? Will the above be able to use the NopObjectContext?)
Proposal of a modified nopCommerce architecture to extend entities
- 79
- 1091
- 5/5/2010
- Spain
New York wrote:
This change only allows extending entities with the use of partial classes. All parts of a partial class must be in the same assembly, because they are put together at compile time, not at runtime. Therefore no, this can't be used from plugins.
[quote](P.S. Why do plugins with data access require their own custom db context? Will the above be able to use the NopObjectContext?)[/quote]
This is just guessing: I think you should be able to use the NopObjectContext, but not to extend it. I believe that once a dbcontext is initialized at runtime, you can't really change it (modify entity mappings and so on). So, I'd think that when the plugins are loaded, it's too late to apply any change to the context.
It's not clear to me if this change is going to allow for adding new entities and relate the new entities to existing entities in a plugin.
For example, I currently have a custom version of nopC where Products have one or more Suppliers. There's a new Supplier entity, and a new ProductSupplier entity (both in namespace Nop.Core.Domain.Catalog), and the Product entity was extended to include a collection of ProductSupplier. (All similar to how a product can have one or more manufacturers). Can all this now be done in a plugin?
For example, I currently have a custom version of nopC where Products have one or more Suppliers. There's a new Supplier entity, and a new ProductSupplier entity (both in namespace Nop.Core.Domain.Catalog), and the Product entity was extended to include a collection of ProductSupplier. (All similar to how a product can have one or more manufacturers). Can all this now be done in a plugin?
This change only allows extending entities with the use of partial classes. All parts of a partial class must be in the same assembly, because they are put together at compile time, not at runtime. Therefore no, this can't be used from plugins.
[quote](P.S. Why do plugins with data access require their own custom db context? Will the above be able to use the NopObjectContext?)[/quote]
This is just guessing: I think you should be able to use the NopObjectContext, but not to extend it. I believe that once a dbcontext is initialized at runtime, you can't really change it (modify entity mappings and so on). So, I'd think that when the plugins are loaded, it's too late to apply any change to the context.
MVP
- 11320
- 100942
- 5/22/2011
- United States
RE: "...no, this can't be used from plugins"
That was my initial thoughts, but the first sentence of the post says "often I got problems to extend an entity with a custom attribute in nopCommerce while developing plugins. "
RE: "...when the plugins are loaded, it's too late to apply any change to the context"
I thought that might be handled by the PostInitialize()
That was my initial thoughts, but the first sentence of the post says "often I got problems to extend an entity with a custom attribute in nopCommerce while developing plugins. "
RE: "...when the plugins are loaded, it's too late to apply any change to the context"
I thought that might be handled by the PostInitialize()
- 79
- 1091
- 5/5/2010
- Spain
New York wrote:
I reread it again and the sentence you mention is indeed confusing, but from the description and the implementation (partial classes) I think there is no doubt that this can't be done in a plugin. What you gain with this is the ability to put all your modifications in your own files, making your life easier during nop upgrades (you only have to merge the project file, but not the code files).
New York wrote:
Yes, but that won't call anything on a plugin. This will call a method in a partial entity initialization class (again it has to be in the same assembly as the other part of the class). Being pedantic, this is not a "postinitialization", but a continuation of the initialization, or a post-core-initialize. What I mean is that the dbcontext initialization will happen at once, not the core one in one step and the extended one in post step.
That was my initial thoughts, but the first sentence of the post says "often I got problems to extend an entity with a custom attribute in nopCommerce while developing plugins. "
I reread it again and the sentence you mention is indeed confusing, but from the description and the implementation (partial classes) I think there is no doubt that this can't be done in a plugin. What you gain with this is the ability to put all your modifications in your own files, making your life easier during nop upgrades (you only have to merge the project file, but not the code files).
New York wrote:
I thought that might be handled by the PostInitialize()
Yes, but that won't call anything on a plugin. This will call a method in a partial entity initialization class (again it has to be in the same assembly as the other part of the class). Being pedantic, this is not a "postinitialization", but a continuation of the initialization, or a post-core-initialize. What I mean is that the dbcontext initialization will happen at once, not the core one in one step and the extended one in post step.
- 17
- 155
- 9/24/2014
- United States
What was the opinion on being able to extend the entity maps? I'm still not able to do this.
Step 2: Extending Entity-Maps
When I have to declare some properties or relationships for the database I need a look at the entity maps. They are located in Nop.Data.Mapping. In this scenario I can’t extend the class with a partial-class because all declarations are done in a constructor.
The only solution is to create a separate abstract base class, let’s say NopCommerceTypeConfiguration, because the mapping classes extend EntityTypeConfiguration<T>. So now I can declare a protected virtual void PostInitialize() method in the new base-class which is calling the method in the constructor.
Step 2: Extending Entity-Maps
When I have to declare some properties or relationships for the database I need a look at the entity maps. They are located in Nop.Data.Mapping. In this scenario I can’t extend the class with a partial-class because all declarations are done in a constructor.
The only solution is to create a separate abstract base class, let’s say NopCommerceTypeConfiguration, because the mapping classes extend EntityTypeConfiguration<T>. So now I can declare a protected virtual void PostInitialize() method in the new base-class which is calling the method in the constructor.