Allright, I found a pretty nice Article on IoC (Inversion of Control)
Understanding IoC Container
[EDIT:]
Also, I have found one way to replace an existing Service with my own code. However I am not sure this is the simplest way.
1. Implement your own Service, subclassing the existing one, and overriding the Methods you need.
2. Write your own IDependancyResolver implementation. It could be a Subclass of UnityDependancyResolver with your own Service registered in ConfigureContainer().
3. Find "dependencyResolverTypeName" in web.config and set the value to your own DependancyResolver.
This way, after an Upgrade all you have to do is put your own DependancyResolver into web.config and eventually adjust the overriden Methods if needed.
This method allows you to override existing Methods, but not to add new ones since the Interface is still unchanged.
Retroviz mentioned using decorator pattern to solve that problem, but I am not sure how to insert that code in the nopCommerce painlessly.
[EDIT2:]
Sometimes I can be such a dummy! Extending the existing services with new methods is actually very easy. Interfaces are partial! Add a new part of the interface, and implement the new methods in another part of the service class. Voilà!
P.S. I hope this method isn't going to change a lot with MVC.
How to - extending nopCommerce (1.X versions)
- 54
- 336
- 2/2/2010
- Austria
From another post:
breakskater wrote:
Can you extend the class file, create a new method, and wrap the existing method, thus adding new functionality pre or post existing method call? Either way you will have to change all caller/dependant classes to either use a new extended method or a new derived child class.
What are you trying to do? If you could add a post to the forum you referenced (so we don't get too far off topic here), I will see if I can help you.
Thanks
In nopCommerce 1.9 you can register your own service instead of the original one, thus overriding it for all calls. Read the post I mentioned above (also follow the link to IoC article). That way you don't have to change all caller/dependant classes if the interface doesn't change.
breakskater wrote:
Can you extend the class file, create a new method, and wrap the existing method, thus adding new functionality pre or post existing method call? Either way you will have to change all caller/dependant classes to either use a new extended method or a new derived child class.
What are you trying to do? If you could add a post to the forum you referenced (so we don't get too far off topic here), I will see if I can help you.
Thanks
In nopCommerce 1.9 you can register your own service instead of the original one, thus overriding it for all calls. Read the post I mentioned above (also follow the link to IoC article). That way you don't have to change all caller/dependant classes if the interface doesn't change.
- 54
- 336
- 2/2/2010
- Austria
I don't see why do you need to pass the context to the service. What is wrong with using the default context?
The thing i would like to see are events before and after important tasks. That way you could insert your functionality just at the right place. For example on "BeforeUpdate" event, one could change the entity before it is saved to the DB.
One other improvement could be that the Resolver doesn't have the type registration hardcoded, but in a configuration file.
The thing i would like to see are events before and after important tasks. That way you could insert your functionality just at the right place. For example on "BeforeUpdate" event, one could change the entity before it is saved to the DB.
One other improvement could be that the Resolver doesn't have the type registration hardcoded, but in a configuration file.
- 54
- 336
- 2/2/2010
- Austria
stimpy77 wrote:
I am sorry, but I just can't seem to be able to find the evil code you are talking about. Could you point me to it(File, line number)?
I don't see why do you need to pass the context to the service.
Not to the service. From the service, to the entity (Customer), which was reading/writing data in the property setters outside of a .SaveChanges() command. This is evil.
Not to the service. From the service, to the entity (Customer), which was reading/writing data in the property setters outside of a .SaveChanges() command. This is evil.
I am sorry, but I just can't seem to be able to find the evil code you are talking about. Could you point me to it(File, line number)?