Developer roadmap - 2. Architecture improvements. Your thoughts.

Hi folks,

I've created this topic in order to know your thoughts and suggestions about further architecture improvements (and performance etc). Here are my thoughts:

Architecture improvements:
1. Usage of IoC/DI pattern. I personally prefer autofac library over StructureMap and Unity. But of course implementing this pattern will affect all existing nopCommerce sites (I mean upgrading and moving away from static managers).
2. More pluggable architecture. And it should not require source code changes.
3. Add web service API support
4. Pass entities as parameters to Manager methods. For example, OrderManager.InsertOrder(Order order) instead of OrderManager.InsertOrder(Guid orderGuid, int customerId,...other parameters)
5. Use PagedList instead of most of the stored procedures. See the post of Ben Foster ('nopCommerce team | retroviz' username) here for more info
6. Move to MVC. Please discuss this task here
7. Repository pattern
8. Entities should be persistence ignorant. They should not depend on managers/services (remove custom properties).

Performance optimization:
1. Optimize nopCommerce for catalogs with more than 100,000 products
2. Precompiling linq querries (...but this change will complicate the source code for further modifications)
3. Caching. More extended caching mechanism. Let's allow developers to decide whether entities should be cached per request or between requests. Original topic is here
4. Full-text search support
5. Use lucene.net for search (Thanks, Will)

Let's discuss these suggestions. Let's discuss your ones.

I really enjoy the speed at witch we move forward with the framework. It is a great challange and keep's me sharp. I se no problem in updating often. The only thing that I feel is more important than the speed of change is the response time that real customer's experience when they hit my page. So resources should focus on performens improvements. Hopefully there is a way to achive this and at the  same time move forward.

Best regards
Thomas
http://www.slikfabrikken.dk

Yes, it's the customer experience that should count.

I like and use nop but because of the slowness i'm still looking away to other webshops. You should make time to add some nice templates like "the handbag" theme. Ajax filtering, speed up the buy experience (auto add adresses), add paging in the forum, go to last unread reply in the forum, etc.

I guess with your knowledge, not a very interesting job but it can be done in a few weeks

For me, I prefer Unity, because:

Every IoC has it's own advantages/disadvantages, paradigms, usage practicies, but in .NET world we have one significant player - Unity (whether we like it or not).

For an in-house company project - it is not an argument - every single team can choose any dependency injector, which is more liked by most of the team members, but if we talking about public open-source project we should consider industry trends first.

Hi andrei.

here are my thoughts regarding the points above:

Architecture improvements:
1 - The use of IoC is almost a must for the future of nop. however we have to be really careful with the choice of the library to use. there are quiet a few out there and all have Pros and Cons. My personal and modest opinion is : Stay as close as possible to Microsoft standards. that will last. the other libraries have evolved but many rely on other OS libraries as well and depend on them. nobody knows where they'll be in the future, if they'll be still around and supported ...... too many questions arise.

I applaud your decision to go with EF instead of other ORM.  it was the right one. i hope to see you go with unity in this case.

2 - YES. great idea. take a look at Ninject. it allows you to throw an assembly in the bin directory and it'll load it and make it available to the application. i like that but still find it too loose. In this case i would rather see an assembly registration feature in the system menu of the admin. Upload a zip file that include all needed dll and let nop decompress and place the files in the right place. this way you could upload a new control, template, feature... and maybe even give it a name, label, assign it to a new menu item if it has a UI..... a whole new way of customizing nop and a true plugin architecture.

3 - 4 : That would be great. i think it is the way to go.

5 - Absolutely.

6 - MVC is the future. it currently supports HTML5 (through some templates) and believe it will natively in future versions. MVC and HTML5 support will be a major must have very soon.

Performance optimization:

1 - Nop is gaining popularity by the day and poeple are making plans for their businesses. the web is getting larger also  by the day and being able to support large catalogs is very recommended.

2 - I think it would be a great pllus if we can do that and give it a way to be customized. i have read an article on how to compile linq queries from within the application. this would allow you to make changes and click a fire an event to compile the queries. i'll see if i can find it and forward it to you.

3 - defenetly an area that needs improvements. please take a look at this caching library. it might be what we need.

4 - good to have but i think it should come after all the previous improvements and make it more SEO friendly.  


One more thing we might have overseen : We need to think of a way to have static content, images, texts, scripts, styles ... .... loaded from different urls then the main store. it would significantly improve the page loading time.


Thank you.

StructureMap or Ninject would be my choice of IoC container. StructureMap also has assembly scanning features making it very good for plugging in functionality.

That said, I believe MVC 3 is going to make it really easy to swap out dependency containers so everyone can use their favourite :)

I am very keen on clean,pluggable and extensible architecture. But also I always debates with myself about the tradeoff between the beauty of the architecture and the performance. Here is my 2 cents.
1. IoC/DI is a must in terms of extensiblity. CommonServiceLocator is needed to make the switch of the IoC possible.
I use Windsor Castle because it can do AOP(now Unity has this functionality too). The problem of Unity is the releasing cycle for Enterprise Libraries is too long in the past(about 1 year).
2. I used linq to sql and implemented the paged list before in one of my projects. But I am not sure whether Stored procedure should be totally replaced with inline sql or not. First thing is transaction support,transactionscope can be upgrade into distributed transaction sometimes and the performance might not be good. Unit of Work pattern should be applied here.
3. Cache management is really hard to decide. Many people like me don't like sql cache dependency. I have never use the cahce block in the enterprise libraries but it might be something to consider.
4. I am not sure if MVC is the future. But seperation of concern is definitely a must, it can be implemented in web form application also(aka MVP). I don't like the inline rendering code in MVC, but I don't like the viewstate in webform page either.
4. Stay away from microsoft ajax, use JQuery instead.

Zhicheng Su

Use lucene.net for search - I have the code for this should you want it.

Test searching over 10k products here: www.shortersclub.co.uk and www.ryness.co.uk

#4 yes but don't constrain the usefulness of the DLLs for other programs (e.g. inserting orders programatically from other programs/sites).

Start using ReSharper to keep the code tidy and consistent. As open source devs you can get a free licence.

thought wrote:

Wow, thats fast. I want to try this too. I will send you an PM.