如何大MVC 4应用程序划分为多个较小的应用程序？ [英] How can a large MVC 4 application be divided to multiple smaller applications?

问题描述

我有一个 ASP.NET MVC 4 Web应用程序分割在多个领域在Visual Studio 2013。

I have an "ASP.NET MVC 4 Web Application" divided in multiple areas in Visual Studio 2013.

该项目发展到大，我目前在应用了大量的区域范围。

The project grown large to the extent that I currently have a large number of areas in the application.

有，可以在另一个的MVC 4应用程序通过本身来分隔的一个特定区域。我创建了一个新的MVC 4应用和移动这个区域到该应用程序。

There one specific area that can be separated in another MVC 4 application by itself. I created a new MVC 4 application and moved this area to that application.

这是我面临的问题：

1. 的移动区域使用从原来的应用程序的其他类code。包含一些属性，以及一个<青霉> BaseController 的
具体地讲，有共用区域

2. 在移动领域的意见也使用JS脚本和其他内容。大部分时间，所使用的脚本不是排他性或特定于使用它们的面积。所以内容是跨多​​个领域中被引用。

下面是我的尝试：

1. 要解决编译错误，我试图从旧的MVC应用到新的MVC应用程序添加引用，因此，在新的应用程序中的类可以看到在旧的应用程序的其他类，如共享区域类。然而，这似乎并没有解决问题。


2. 要解决JS脚本和内容问题，我创建了一个解决方案文件夹，并感动了所有的脚本给它。不过，我无法证实这是否是由于编译错误或工作不因为我可以启动应用程序。

下面是我的问题：

1. 是否VS2013提供一些设施，以分离MVC应用程序或制作一个应用程序是指从另一个应用code和内容？


2. 什么你认为是最好的策略，使这种分离？

我尝试了如何实现这种分离SO和谷歌搜索。不过，我发现似乎适用于MVC和VS的previous版本由于我是新的MVC领域和MVC的一般我不解决这个得到的概念。

I tried searching SO and Google for how to accomplish such separation. However, what I found seems to be applicable to previous versions of MVC and VS. Since I am new the concept of MVC areas and MVC in general I can't get around this.

推荐答案

我将采取的视图问题的更普遍一点。这不是专门的ASP.NET MVC的问题，而是一个.NET code的组织问题。我不相信有任何一个具体的规范方法，而一些一般原则根据您的preferences以及如何你的项目/团队的工作方式提供帮助。

I would take a more general point of view on the problem. It's not specifically an ASP.NET MVC problem, but rather a .NET code organization issue. I don't believe there's any one specific canonical methodology, rather some general guidelines to help depending on your preferences and how your project/team works.

整体项目我会注重的是分手的code为独立的组件并创建一个资产的管道。

The overall items I would focus on is splitting up your code into separate assemblies and creating an asset pipeline.

拆分组件可以让你的项目进行编译和重新编译独立，根据需要。这样做的好处，如果你需要拆分跨机器的东西Web服务和再利用像WCF服务等相关项目，或者如果您需要根据您的要求做这样的事情GAC特定组件。

Splitting assemblies allows your projects to compile and recompile independently, as needed. This has the added benefit if you need to split things across machines in web services and re-use in other related projects like WCF services, or if you need to do something like GAC specific assemblies depending on your requirements.

把东西放进管道只是让共享和管理都比较容易。

Putting things into a pipeline just makes sharing and managing everything easier.

下面是一些建议：

• 您不必在你的，它听起来像你所拥有的一切解决方案1单片项目。东西分割成多个项目，导致多个组件。您也可以有不需要其他部分运行应用程序的独立部分的多个解决方案。

• You don't need 1 monolithic project in your solution for everything which it sounds like what you have. Divide things up into multiple projects, resulting in multiple assemblies. You can also have multiple solutions for independent pieces of the app that don't need other pieces to run.

开始与任何后端和业务逻辑，在整个应用程序共享。例如，如果你有一个由多个意见的CustomerService类，把它弄成MyCompany.MyApp.Services。显然，更精细的，你得到的，更具体的您的命名可能会得到，如果你最终会加入大量的项目。

Start with any "back-end" and "business" logic that is shared throughout your application. For example if you have a CustomerService class that is used by multiple views, put it into something like MyCompany.MyApp.Services. Obviously, the more granular you get, the more specific your naming might get if you end up adding lots of projects.

有关MVC型项目，特别是，它通常是很容易你的模型分成1个或多个组件。例如：MyCompany.MyApp.SomeGroupingName1.Models和MyCompany.MyApp.SomeGroupingName2.Models，或者干脆到1为MyCompany.MyApp.Models

For MVC type projects specifically, it's usually very easy to split up your models into 1 or more assemblies. Example: MyCompany.MyApp.SomeGroupingName1.Models and MyCompany.MyApp.SomeGroupingName2.Models, or simply into 1 as MyCompany.MyApp.Models

您可以将控制器分成多个组件，以及，同为previous点。

You can split your controllers into multiple assemblies as well, same as the previous point.

您可以提取任何种类的UI到自己组装的组件为好，也一样的看法。

You can abstract any kind of components in the UI into their own assemblies as well, same goes for views.

正如你所提到的解决方案使用的文件夹。

Use solution folders as you mentioned.

如果需要帮助建立并解决资源捆绑引入资产管理库。如果库已经不这样做，你可以创建一个资产的管道，这种插入做CSS和JS的缩小。然后在你的应用程序，你只需引用您在您需要的页面需要管束，而不是总包括每页的手动一切还是在整个应用程序在整个网站分享一切。

Introduce an asset management library if needed to help build out and solve the bundling of resources. If the library doesn't already do this, you can create an asset pipeline that this plugs into to do minification of css and js. Then in your app you simply reference the bundles you need in the pages you need, rather than always including everything manually per page or sharing everything in the whole site in the whole app.

在继承preFER成分可能的情况下。这不是从您的文章清楚，但我所看到的许多问题与人们试图实现一个统治他们所有的基类，每个控制器，视图等它可能工作，因为他们说，直到它没有。仍然是一个好主意，用基类和继承，但不打领带多东西，做不同的事情，以相同的基本实现。在这一点上，接口可能会更你想要什么，如果你需要实施某种形式的合同。

Prefer composition over inheritance when possible. It's not clear from your post, but I have seen many issues with people trying to implement a one rules them all base class for every controller, view, etc. It might work, as they say, until it doesn't. Still a good idea to use base classes and inheritance, but don't tie multiple things that do different things to the same base implementation. At that point, an interface might be more what you want if you need to enforce a contract of some kind.

最后一点：如果您在内容管道捆绑的东西，客户减少的时候，他们下载你的脚本，如果你这样做是正确的金额，你可以在浏览器尝试缓存用于其他页面。有时好推一个大文件下来比一次做出许多网络连接的每一页，那些在你的意见是内联没有得到轻易缓存不同的文件或事物。

A final point: If you bundle things in your content pipeline, the client minimizes the amount of times they download your scripts if you do it right, and you can have the browser try to cache it for other pages. Better sometimes to push a big file down once than make many network connections every page to different files that don't get cached easily or things that are inlined in your views.

这篇关于如何大MVC 4应用程序划分为多个较小的应用程序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！