Code Generation

Hi Guys,

I'm wondering, does the NopCommerce development team use any Code Generation tools like CodeSmith, Microsoft's T4 or something similar?

The reason I ask is that I'm looking to implement some extensions to NopCommerce 1.50 and it seems to me that much of the DAL can indeed (and in fact HAS indeed been generated).  What led me to this conclusion is the fact that all SQLProvider objects seem to have their method parameters in PascalCase rather than the expected camelCase, which would make sense only in the case that it was generated from the DB and no case conversion was implemented in the template.  I don't otherwise see how/why these would be in PascalCase, as that does not seem consistent with the coding standards in the rest of the application.

In fact looking through the application there is a strange mix of camelCase and PascalCase used in method arguments.  For example in ProductManager.cs in the Nop.BusinessLogic/Products folder there are 2 GetAllProducts methods.  One has showHidden as an argument in camelCase, while the other has PageSize, PageIndex and TotalRecords arguments in PascalCase (which I found rather weird).  It almost seems like some of the code was generated and then handmodified and extended from there.

Either way it seems what's currently there is a bit all over the place and certain doesn't meet Microsoft's coding standards in relation to capitalization (http://msdn.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx) and would also come up as an issue in FxCop.

Anyways, would love if someone could shed some light on this.  I think other than this NopCommerce is a very well architected solution.

I'm pretty sure everything is written by hand :)

Hmm, it doesn't look that way given that it's the only place they havn't followed coding conventions of using camelCase for parameters...  Any chance anyone from nopCommerce could comment?

Actually to be honest it's a little concerning that there aren't coding standards in place for something like this.  I mean the solution is quite well architected.  Also it's not all that hard to use FxCop when developing a solution like this and I would that's something they should/would do.

Sheldmandu wrote:

I can confirm that all source code is hand-crafted.

Regarding naming standards. Thanks for suggestion. We'll use FxCop and try to match all naming standards in the next release.

Thanks for confirming this Andrei.  It's great to hear that you guys are willing to take suggestions onboard.  Using FxCop should really help with improving code quality and standardising development practices.  Of course some things flagged by FxCop are just warnings and suggestions and can be easily turned off, but others are very valid.

I think you guys have put together a great product and it certainly is miles ahead of DashCommerce and DotNetNuke shopping cart plug-ins in terms of its functionality and architectural quality (just needs a few loose ends tied up).

Having looked through the architecture very closely it is very much how I personally would have architected it.  Just FYI here are some minor things I probabably would have done differently... It's not something I would expect anyone to change but thought I'd share just so you can consider it for future projects and perhaps for nopCommerce at some stage.

1. Use of parameters instead of Data Transfer Objects in the Data Access Layer.  It's pretty common and often better and easier to use Data Transfer Objects instead and passing these in the application instead of individual parameters.  This yields much cleaner code.  Yes, you introduce a dependency that your entire application effectively depends on your DTOs (Entities), but that's a common trade-off to get much cleaner code and doesn't introduce any issues as such.

2. Use of static methods in manager classes.  Like you I have in the past used static methods for manager objects, but after having build a few big applications using that concept I discovered the major drawback of doing so... It's not possible to use inheritance to override certain methods if you need to do so because you have the need to have a different manager class (for different products for example).

3. I noticed that in some places you guys choose to use multiple queries instead of a single query to retrieve data to construct multiple objects.  I guess generally this isn't a problem, but you may find that on high traffic websites this may impact performance (but then again, using a dedicated server/s should probably solve the issue.  I guess as long there aren't many cases where queries are being done in a loop there shouldn't be too many issues.

4. There's probably no reason not to use Code Generation.  Using Microsoft's T4 Code Generator or CodeSmith would probably speed up development quite a bit where you're introducing new DB tables and new functionality.

You guys may also find that Martin Fowler's Patterns of Enterprise Application Architecture book may be of much interest to the team as it discusses many of these considerations.

Hope you find this info useful. GREAT PRODUCT!

Thanks for well explained suggestion. We'll think about all of them.

And thanks for the book. I did read it. Just great! Highly recommended for every developer.