Organize your ASP. net mvc Solution

Recently, Twitter launched an "your favorite Asp.net MVC project organization method". I have studied some methods to organize project files. I have always liked to use a few flexible statements. In addition, this method is very simple.

For example, there are only two projects in the solution. First, let's look at the UI project. The UI project only containsRelated to websiteAndDoes not contain any backgroundCode, Which includes:

• No Controller
• No model
• No global. Asa. CS
• Does not contain any background code

Why not include background code? Because the UI project only contains those files related to the UI, and my UI project matches with the deployment project, this includes

• Views
• CSS
• Images
• Global. asax
• Web. config
• Reference a core project

Because my UI project matches the deployment structure, it is easy to figure out how development works. otherwise, mixing model and controller makes it difficult to separate parts in development. Therefore, my organization method separates the code from the content.

What should we do with the code? Put it in another project, which I like to call "core". Of course, you can just name it. All the code files will be put in this project, including the persistent layer model, view model, controller, repositories, Orm-related files, and any background code-related parts.

Organize your code

For organized code, I like to use a simple method. If possible, I would rather not compile the UI project-this is just a folder for storing content, the bin directory in this folder only contains the DLL from the "core" project.

In addition, I like to use folders to organize code. You can use projects to organize code, but this kind of lack of flexibility will block you in layers and structures that are hard to change. I have already made many mistakes in large projects due to incorrect Organization Code. In the end, I found that the best practice is not great, because a team I once stayed in often has hundreds of projects, but less than half of the projects were actually deployed. so remember that the time required for compilation depends largely on the number of items in your solution. Compare a project containing 1000 files and 100 files in 10 projects. The compilation time required by the former is much smaller than that of the latter. At least in projects I have ever seen.

Another practical problem is that when you need to reorganize your existing code, you will find that for solutions that contain N projects, the fact that you are banned from the structures of different projects will make you feel at ease. In addition, when Ctrl + F5 is used for debugging, the ultra-slow speed will make you cry. However, when your code is managed by the source code management software, it is even more inadequate. Moving a file from one project to another will increase your history. In one of my recent projects, the situation has evolved to the fact that even a simple source code control command cannot be executed, leading to the loss of all our source code control history records, finally, we had to manually create the entire project. Moving folders is much more comfortable than moving files in projects...

If you want to organize and stratify your code, it may be helpful to use projects because it forces you to follow the rules you set at the beginning, but once you start doing this, you have set up "common" project, "configuration" project ", and" mapping "project, in subsequent development, it is best to consider returning the code to the same project.

So, why don't you consider putting all the code into one core project, and all the UIS into one project, which can give you great flexibility and the fastest Compilation speed? No matter what architecture you prepare to organize your code, make sure that you do not put the background code into the UI project so as to avoid confusion between the separation of focus structure of code and content.

-----------------------------------------------------

Link: http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/12/08/organizing-asp-net-mvc-solutions.aspx