The following is discuz! NT folder root directory:
Class Kuto:
From the above two graphs can be seen:
1. dnt hierarchies for class libraries are differentiated by the hierarchy of names, such as Discuz.plugn and Discuz.Plugin.Spread
2, in the folder hierarchy is also following the 1th form (in addition to the Admin project, the Admin project uses the technology of the child site, so is included in the Discuz.web folder inside, reference: http://www.cnblogs.com/EasonJim/ archive/2013/05/06/3062571.html).
This can be summed up from the above:
1, there is a clear hierarchy in the class library hierarchy, you can quickly distinguish which class library affiliation, and the reason for the sorting can be quickly categorized.
2, the folder does not adopt the form of nesting, unified new in the root directory, the name is also followed by the 1th, so there is a benefit is later even if the project to sub-folder storage, as long as the solution of VS with virtual folder instead, change without affecting the physical folder at any time.
3, on the physical folder I can also quickly until there are those class library, do not look back and forth on the nested folder.
Therefore, in our existing e-commerce projects to use the above way to build a project is a good choice.
For example, in the past when we built the BLL, there could be bll.sms and BLL. E-Mail ... These business modules, and we will in order to clean up these business modules unified set up a BLL folder to store, and then unified reference on VS, and finally on vs also set up a BLL virtual folder, and then classify, the disadvantage is: if one day I change the idea, redefine the hierarchy, Then change from the physical folder to the virtual folder of vs.
So, with the DNT scheme, I change my mind one day to layering, the virtual folder changes directly on VS, without moving anything.
From discuz! NT project file structure to see how to give the system framework hierarchy and Class Library sub-folders