Hi,
We need to add some regional information in NopCommerce context to control some actions and expand the standard information with local information. Which is the best way to do that? Are there any guideline of best practice? We are looking for a solution to preserve all of NopCommerce code intact to facilitate future upgrades.
How to - extending nopCommerce (1.X versions)
- 2
- 10
- 9/18/2009
- India
I added a new Sp in v 1.9 , but i am getting below error
System.InvalidOperationException was unhandled by user code
Message=The type parameter 'NopSolutions.NopCommerce.BusinessLogic.Promo.Events.Nop_Event' in ExecuteFunction is incompatible with the type 'NopSolutions.NopCommerce.BusinessLogic.Data.Nop_Event' returned by the function.
Source=System.Data.Entity
System.InvalidOperationException was unhandled by user code
Message=The type parameter 'NopSolutions.NopCommerce.BusinessLogic.Promo.Events.Nop_Event' in ExecuteFunction is incompatible with the type 'NopSolutions.NopCommerce.BusinessLogic.Data.Nop_Event' returned by the function.
Source=System.Data.Entity
MVP
- 751
- 4113
- 1/24/2009
- United Kingdom
nakamoto wrote:
I think it will be difficult to make such changes without changing some core code.
I'm assuming that you want to do something like restrict the products that can be viewed/purchased based on region of the site and/or customer.
My suggestion would be that you create a generic regionalization filter that can be applied to any IQueryable<T>. You would need to have the entities that should be filtered by region implement a common interface or inherit a common base class. This would allow you to store restrictions in one central table (e.g. entity type and entity id) rather than having a separate table for each entity regional restrictions.
The region filter would be a query extension for IQueryable<T> where T is the base class / interface you have created.
However, even with the above, you would still need to change the core code to apply your region filter.
That's how I would go about doing it anyway.
HTH
Hi,
We need to add some regional information in NopCommerce context to control some actions and expand the standard information with local information. Which is the best way to do that? Are there any guideline of best practice? We are looking for a solution to preserve all of NopCommerce code intact to facilitate future upgrades.
We need to add some regional information in NopCommerce context to control some actions and expand the standard information with local information. Which is the best way to do that? Are there any guideline of best practice? We are looking for a solution to preserve all of NopCommerce code intact to facilitate future upgrades.
I think it will be difficult to make such changes without changing some core code.
I'm assuming that you want to do something like restrict the products that can be viewed/purchased based on region of the site and/or customer.
My suggestion would be that you create a generic regionalization filter that can be applied to any IQueryable<T>. You would need to have the entities that should be filtered by region implement a common interface or inherit a common base class. This would allow you to store restrictions in one central table (e.g. entity type and entity id) rather than having a separate table for each entity regional restrictions.
The region filter would be a query extension for IQueryable<T> where T is the base class / interface you have created.
However, even with the above, you would still need to change the core code to apply your region filter.
That's how I would go about doing it anyway.
HTH
- 115
- 593
- 9/28/2010
- Brazil
Hi Ben,
Thanks for your post. It wil be helpful in the future aproach
When we will use NopCommerce to work as our B2B solution.
By now, the regional information i said are Brazilian documents
Numbers that we need to ask for the customer when they are
Filling the registration form, ok? I guess it is easier
Than you imagine, but we are pretty new in NopCommerce
Architecture, thats why i ask about ...
Thanks again.
Thanks for your post. It wil be helpful in the future aproach
When we will use NopCommerce to work as our B2B solution.
By now, the regional information i said are Brazilian documents
Numbers that we need to ask for the customer when they are
Filling the registration form, ok? I guess it is easier
Than you imagine, but we are pretty new in NopCommerce
Architecture, thats why i ask about ...
Thanks again.
- 33
- 213
- 11/22/2010
- United States
Huh? Eh .. wait .. if the region information is associated with, say, the customer and/or product, then why can't one just create an override class for CustomerService (and/or ProductService), with overridden Customer/Product and related objects being passed out, and put in the IoC container that the implementation for ICustomerService is your override? Doesn't the IoC container drive off the web.config? And if not, can it, e.g. perhaps from global.asax?
If this is not the case then would it not seem that the IoC container implementation was wasted?
If this is not the case then would it not seem that the IoC container implementation was wasted?
- 33
- 213
- 11/22/2010
- United States
Re the OP, this was a helpful article. However, it only discusses the expansion of data models. Extensibility of nopCommerce as an application, including a programmatic plug-in model, etc, should be implemented, or documented if it already is. For example, as my previous post suggested, one should be able to override or remplement classes returned by IoC.Resolve<T>; as we are using C# 4.0, one should not have to modify the Nop.BusinessLogic.dll project to make fundamental changes to the nature of the business logic.
Extension via partial classes is handy at the time of coding, but it has made it impossible for us to be able to write extension code that we can even hope to be upgradeable from one version to the next without a very painful Beyond Compare merge process.
Extension via partial classes is handy at the time of coding, but it has made it impossible for us to be able to write extension code that we can even hope to be upgradeable from one version to the next without a very painful Beyond Compare merge process.
MVP
- 751
- 4113
- 1/24/2009
- United Kingdom
stimpy77 wrote:
Jon,
Yes this is another (and better) way of doing it. You would not be able to inherit directly from the existing service since the methods are not virtual. You could however use the decorator pattern (implement I[Whatever]Service with a dependency on I[Existing]Service). You can then use the IExistingService methods and provide your own implementations when required.
It's worth noting that simply filtering the results of the existing service is probably not a good idea since most of the service methods return IList implementations so you would be doing in memory filtering.
One thing we should perhaps consider for the future is whether we can inject filters (a bit like LinqSpecs) so that the source IQueryable collection can be filtered. This would be perfect for cases like this.
Huh? Eh .. wait .. if the region information is associated with, say, the customer and/or product, then why can't one just create an override class for CustomerService (and/or ProductService), with overridden Customer/Product and related objects being passed out, and put in the IoC container that the implementation for ICustomerService is your override? Doesn't the IoC container drive off the web.config? And if not, can it, e.g. perhaps from global.asax?
If this is not the case then would it not seem that the IoC container implementation was wasted?
If this is not the case then would it not seem that the IoC container implementation was wasted?
Jon,
Yes this is another (and better) way of doing it. You would not be able to inherit directly from the existing service since the methods are not virtual. You could however use the decorator pattern (implement I[Whatever]Service with a dependency on I[Existing]Service). You can then use the IExistingService methods and provide your own implementations when required.
It's worth noting that simply filtering the results of the existing service is probably not a good idea since most of the service methods return IList implementations so you would be doing in memory filtering.
One thing we should perhaps consider for the future is whether we can inject filters (a bit like LinqSpecs) so that the source IQueryable collection can be filtered. This would be perfect for cases like this.
MVP
- 751
- 4113
- 1/24/2009
- United Kingdom
stimpy77 wrote:
Jon,
Yes, such was the scope of my article since this was a common question on the forums.
nopCommerce only really became pluggable in my eyes in 1.90, when we started using an IoC container to resolve dependencies. The next version(s) of nopCommerce will make much more use of dependency injection to provide a pluggable model. It is something that is a high priority in future versions.
Re the OP, this was a helpful article. However, it only discusses the expansion of data models. Extensibility of nopCommerce as an application, including a programmatic plug-in model, etc, should be implemented, or documented if it already is. For example, as my previous post suggested, one should be able to override or remplement classes returned by IoC.Resolve<T>; as we are using C# 4.0, one should not have to modify the Nop.BusinessLogic.dll project to make fundamental changes to the nature of the business logic.
Extension via partial classes is handy at the time of coding, but it has made it impossible for us to be able to write extension code that we can even hope to be upgradeable from one version to the next without a very painful Beyond Compare merge process.
Extension via partial classes is handy at the time of coding, but it has made it impossible for us to be able to write extension code that we can even hope to be upgradeable from one version to the next without a very painful Beyond Compare merge process.
Jon,
Yes, such was the scope of my article since this was a common question on the forums.
nopCommerce only really became pluggable in my eyes in 1.90, when we started using an IoC container to resolve dependencies. The next version(s) of nopCommerce will make much more use of dependency injection to provide a pluggable model. It is something that is a high priority in future versions.