Are there any advantages or disadvantages to using one or the other?
If you're using generic repositories, you don't have to write much code. You don't have to add a new repository class and implement CRUD logic when you add a new entity. All you have to do is just pass IRepository<NewEntity> to appropriate service/manager. If you want to move to nhibernate, all you need to do is to implement IRepository<T> (similiar to EFRepository<T> that you can find in my previous post) and describe your model (mappings). Generic repository has more advantages and is the more preferred way to go. But you cannot add some custom or complex logic to this generic repository. Here are some other thoughts
Are there any advantages or disadvantages to using one or the other? If you're using generic repositories, you don't have to write much code. You don't have to add a new repository class and implement CRUD logic when you add a new entity. All you have to do is just pass IRepository<NewEntity> to appropriate service/manager. If you want to move to nhibernate, all you need to do is to implement IRepository<T> (similiar to EFRepository<T> that you can find in my previous post) and describe your model (mappings). Generic repository has more advantages and is the more preferred way to go. But you cannot add some custom or complex logic to this generic repository. Here are some other thoughts
After reading about this further, it seems that having specific repositories are more beneficial than generic since each entity will have its own unique requirements. What do you think?
For those of us who don't want a theoretical max on product orders, or maybe want to limit it to your available stock quantity, you'd be able to improve performance a bit removing the asp.net validations on txtQuantity and writing custom javascript to do it.
Right now, there's a block of code for every single product variant on a product page which if you have many variants can add up to as much (or more) extra text as the Viewstate. For example, one of my pages that has a dozen or so variants has 44000+ characters in javascript for simply stock quantity validation.
I think that could be eliminated by adding something like class="txtQuantity" to all of the Quantity text boxes, then writing validation like
//Validate quantity inputs in client side $("input .txtQuantity").change( function(){ var value = parseInt($(this).text());
if( value < <%= MinValue >% || value > <%= MaxQuantity %> ) { // do error handling stuff here and disable add to cart button } });
That should pretty significantly reduce page size. In the case of my pages, we're talking 44KB or more for this page, and this isn't even close to having the most variants! I think I just found my next thing to code up for performance gains.
I think adding web-services, would be great! I voted for this topic in the issue tracker, I think this could also be related to "Multi-store", as a good management console could be created to manage multiple catelogs, and gather the data and sync between the stores via WS endpoints.
Also, wanted to suggest that any WS methods include the ability to let 3rd parties (say if a store was acting as a drop-shipper) to call a web-serivce to place and order, check inventory, prices, and/or product descriptions.
I integrate webservice calls into stores that call drop-shippers using these hooks in X-Cart and it's really helpful for making orders appear as if they are coming directly from another store, when actually they are coming from a drop shipper.
I'm not so experienced in writing server side data access applications but isn't there a problem having a static objectcontext object which is the case in NopCommerse. If many clients are trying to reach the same object context simultaneously that will probably lead to some possible errors. Web applications are threaded and in this case it would lead to many threads trying to work with the same object simultaneously, or have i totaly missunderstood the concepts of multithreaded applications?
Those all sound great. #1) I vote Unity. Used it recently and its made some complex issues disappear and lowered the amount of code necessary to get to point B. #4) While it won’t affect me one way or the other I definitely think you should do that. I always prefer methods that complex objects as opposed to multiple simple types. The complex object can be added/extended as time goes on without having to change your interface thus avoided unecessary overloads. #5) About the part of moving off stored procedures I totally agree with that. I HIGHLY recommend using MS Entity Framework as the business layer. Used it on a recent Silverlight project and its awesome. My only suggestion is to treat databases and their columns like you would a full-fledged c# variable in terms of naming convention. I can’t stand those old school underscores and people who still use all caps in their db implementations! Entity Framework really does reduce the amount of code you have to write and continually update as your model grows. #6) Just make sure you use the Entity Framework for you “Model” and don’t go the old school route and do it manually ;)
Almost forgot, any chance of switching to Peter Blum's Data Entry Suite for the validation to give us all not only better control but allow more complex scenarios? I see a real lack of data validation on a lot of controls other than making sure a field has data in it. No offense but this application is very unsecure right now (1.80).
Also baking in ajax post backs for some functionality would be great. E.g. adding a biling address could ajaxified as a modal window instead of a whole new page requiring a full postback.
Just a thought - would it be good to implement Microsoft Enterprise Library for data access?
The Microsoft Enterprise Library is a collection of reusable software components (application blocks) designed to assist software developers with common enterprise development cross-cutting concerns (such as logging, validation, data access, exception handling, and many others). Application blocks are a type of guidance; they are provided as source code, test cases, and documentation that can be used "as is," extended, or modified by developers to use on complex, enterprise-level line-of-business development projects.
Have you thought of making nopCommerce asyncronous? Every call to the server can be called by using seperate threads. Silverlight uses this model. Can ASP.NET use this model as well?
Have you thought of making nopCommerce asyncronous? Every call to the server can be called by using seperate threads. Silverlight uses this model. Can ASP.NET use this model as well?
Great Idea! Last week I've tested the new Visual Studio Async Library and was impressed how easy and fast it is.
