1. In order to make nopCommerce more pluggable I think that all methods must take only 1 business object parameters instead of n parameter like now. I’m talking about the Manager Classes and Data Access Classes. Look at PlaceOrder method in OrderManager it takes almost 90 parameters ( a nightmare if you want to extend this method), if this method will have only 1 bussiness object (Order) as parameter if you want to extend this you will have to add a new property in Order and DBOrder and change only The Sql Data Access method.
2. All the manager classes should be interfaces and loaded with dependency injection (Ex: Unity). With this if you make some modification you will have to extend the manager and override only the target method (which will have only 1 business object)
3. The mapping methods between Business object and Data objects should use something like AutoMapper (http://automapper.codeplex.com/ ) it’s faster to write the mapping rules and if you want to extend an object you will add only a new mapping rule instead of overriding the mapping method.
4. Split the application in 2 : the admin app and client app. All the methods used in client site should be web service methods (WCF). In this way you can make your presentation site in whatever technology you want. With this it will be put the foundations of managing multiple client sites from one admin app
Thanks guys. You are making a great job.
paliktar
Points on the future of nopCommerce
MVP
- 751
- 4113
- 1/24/2009
- United Kingdom
paliktar wrote:
1 - Agree, so many parameters make extending or maintaining these methods a nightmare.
2 - Definitely 1 up for using an IoC container although StructureMap FTW! :p A big win for DI is that it makes everything more testable which brings me to my next point, we need some proper tests in nopCommerce.
3 - Personally I think we should scrap the data objects and go for a DDD approach and repository pattern. For me, our domain objects are what is important. Let the repository figure out how to save them. The db objects currently don't server much purpose and in most cases are identical to their business counterparts.
4 - Can see where you are going with this but this would be a massive job with the current codebase and I don't think there is that much of a requirement for this at the moment - presuming everyone is happy managing their store through a browser and doesn't want a thick client app?
A few more requests / suggestions:
5. Switch to Mercurial for source control - it's now supported on CodePlex. It really makes developing against a remote repository so much easier
6. We need a quicker release cycle. Currently it is one fairly major release every 3-4 months. I would like to see much more frequent minor releases (containing bug fixes, minor feature enhancements etc.). And if you switch to mercurial you will find this even easier to do.
A project that has recently switched to Mercurial is mojoPortal. You can read http://blogs.planetcloud.co.uk/mygreatdiscovery/post/Setting-up-a-mojoPortal-development-environment.aspx this blog post that demonstrates how you can set up your own custom projects whilst still being able to pull in the latest changes from the remote repository.
1. In order to make nopCommerce more pluggable I think that all methods must take only 1 business object parameters instead of n parameter like now. I’m talking about the Manager Classes and Data Access Classes. Look at PlaceOrder method in OrderManager it takes almost 90 parameters ( a nightmare if you want to extend this method), if this method will have only 1 bussiness object (Order) as parameter if you want to extend this you will have to add a new property in Order and DBOrder and change only The Sql Data Access method.
2. All the manager classes should be interfaces and loaded with dependency injection (Ex: Unity). With this if you make some modification you will have to extend the manager and override only the target method (which will have only 1 business object)
3. The mapping methods between Business object and Data objects should use something like AutoMapper (http://automapper.codeplex.com/ ) it’s faster to write the mapping rules and if you want to extend an object you will add only a new mapping rule instead of overriding the mapping method.
4. Split the application in 2 : the admin app and client app. All the methods used in client site should be web service methods (WCF). In this way you can make your presentation site in whatever technology you want. With this it will be put the foundations of managing multiple client sites from one admin app
2. All the manager classes should be interfaces and loaded with dependency injection (Ex: Unity). With this if you make some modification you will have to extend the manager and override only the target method (which will have only 1 business object)
3. The mapping methods between Business object and Data objects should use something like AutoMapper (http://automapper.codeplex.com/ ) it’s faster to write the mapping rules and if you want to extend an object you will add only a new mapping rule instead of overriding the mapping method.
4. Split the application in 2 : the admin app and client app. All the methods used in client site should be web service methods (WCF). In this way you can make your presentation site in whatever technology you want. With this it will be put the foundations of managing multiple client sites from one admin app
1 - Agree, so many parameters make extending or maintaining these methods a nightmare.
2 - Definitely 1 up for using an IoC container although StructureMap FTW! :p A big win for DI is that it makes everything more testable which brings me to my next point, we need some proper tests in nopCommerce.
3 - Personally I think we should scrap the data objects and go for a DDD approach and repository pattern. For me, our domain objects are what is important. Let the repository figure out how to save them. The db objects currently don't server much purpose and in most cases are identical to their business counterparts.
4 - Can see where you are going with this but this would be a massive job with the current codebase and I don't think there is that much of a requirement for this at the moment - presuming everyone is happy managing their store through a browser and doesn't want a thick client app?
A few more requests / suggestions:
5. Switch to Mercurial for source control - it's now supported on CodePlex. It really makes developing against a remote repository so much easier
6. We need a quicker release cycle. Currently it is one fairly major release every 3-4 months. I would like to see much more frequent minor releases (containing bug fixes, minor feature enhancements etc.). And if you switch to mercurial you will find this even easier to do.
A project that has recently switched to Mercurial is mojoPortal. You can read http://blogs.planetcloud.co.uk/mygreatdiscovery/post/Setting-up-a-mojoPortal-development-environment.aspx this blog post that demonstrates how you can set up your own custom projects whilst still being able to pull in the latest changes from the remote repository.
- 13
- 65
- 1/28/2010
- Australia
nopCommerce team | retroviz wrote:
+1 to switch to mercurial, writing patches against the svn tree is a bit painful if they never get commited.
[quote=paliktar]
5. Switch to Mercurial for source control - it's now supported on CodePlex. It really makes developing against a remote repository so much easier
5. Switch to Mercurial for source control - it's now supported on CodePlex. It really makes developing against a remote repository so much easier
+1 to switch to mercurial, writing patches against the svn tree is a bit painful if they never get commited.
- 86
- 590
- 1/11/2010
- Sweden
paliktar wrote:
Now we are talking...
Especially part 4.
I can easily see a scenario where we develop a flash site that talks to back-end for one customer, a regular website for another, or why not an android/iPhone app for someone else...
And I'd really appreciate a really clean theme without all grid/column definitions.
Let (advanced) end users develop their own interfaces with their own master pages. We just need clean webcontrols so we can implement the interface as we will.
I'm pretty new to nopCommerce, but can definitely see a reallly nice future for this if we could separate admin and public parts much more.
Good ideas paliktar, I really hope that some of this will be implemented, and I'd love to see a much more involved developer community behind this one.
I suppose a good API is a way to go, it'd make developing plugins and extensions much easier...
We are now working on web-service based functionality that will place all orders into our distributors system and also update products and order statuses automatically. It'd definitely be much faster if we had an API to play with.
And nop team, thank you for really good work.
1. In order to make nopCommerce more pluggable I think that all methods must take only 1 business object parameters instead of n parameter like now. I’m talking about the Manager Classes and Data Access Classes. Look at PlaceOrder method in OrderManager it takes almost 90 parameters ( a nightmare if you want to extend this method), if this method will have only 1 bussiness object (Order) as parameter if you want to extend this you will have to add a new property in Order and DBOrder and change only The Sql Data Access method.
2. All the manager classes should be interfaces and loaded with dependency injection (Ex: Unity). With this if you make some modification you will have to extend the manager and override only the target method (which will have only 1 business object)
3. The mapping methods between Business object and Data objects should use something like AutoMapper (http://automapper.codeplex.com/ ) it’s faster to write the mapping rules and if you want to extend an object you will add only a new mapping rule instead of overriding the mapping method.
4. Split the application in 2 : the admin app and client app. All the methods used in client site should be web service methods (WCF). In this way you can make your presentation site in whatever technology you want. With this it will be put the foundations of managing multiple client sites from one admin app
Thanks guys. You are making a great job.
paliktar
2. All the manager classes should be interfaces and loaded with dependency injection (Ex: Unity). With this if you make some modification you will have to extend the manager and override only the target method (which will have only 1 business object)
3. The mapping methods between Business object and Data objects should use something like AutoMapper (http://automapper.codeplex.com/ ) it’s faster to write the mapping rules and if you want to extend an object you will add only a new mapping rule instead of overriding the mapping method.
4. Split the application in 2 : the admin app and client app. All the methods used in client site should be web service methods (WCF). In this way you can make your presentation site in whatever technology you want. With this it will be put the foundations of managing multiple client sites from one admin app
Thanks guys. You are making a great job.
paliktar
Now we are talking...
Especially part 4.
I can easily see a scenario where we develop a flash site that talks to back-end for one customer, a regular website for another, or why not an android/iPhone app for someone else...
And I'd really appreciate a really clean theme without all grid/column definitions.
Let (advanced) end users develop their own interfaces with their own master pages. We just need clean webcontrols so we can implement the interface as we will.
I'm pretty new to nopCommerce, but can definitely see a reallly nice future for this if we could separate admin and public parts much more.
Good ideas paliktar, I really hope that some of this will be implemented, and I'd love to see a much more involved developer community behind this one.
I suppose a good API is a way to go, it'd make developing plugins and extensions much easier...
We are now working on web-service based functionality that will place all orders into our distributors system and also update products and order statuses automatically. It'd definitely be much faster if we had an API to play with.
And nop team, thank you for really good work.
- 16
- 80
- 6/12/2010
- United States
Thank you Palitkar. I had settled on nopCommerce as my platform,but i think I will look for some other shopping cart that looks like it's got a plan.
nopCommerce is being developed without a plan it seems to me. Sure, they have a "roadmap", but if things keep changing in the back end, forget it, it's back to work on integrating with other systems.
Regards...
Robert Lobaina
nopCommerce is being developed without a plan it seems to me. Sure, they have a "roadmap", but if things keep changing in the back end, forget it, it's back to work on integrating with other systems.
Regards...
Robert Lobaina