.NET 中文件嵌套,例如:cshtml文件下面嵌套css和js【机器翻译】

愈来愈多的我发现本身在个人一些较大的Web项目中丢失了文件。有不少内容要处理 - HTML视图，几个派生CSS页面，页面级CSS，脚本库，应用程序范围的脚本和页面特定的脚本文件等等。幸运的是，我使用Resharper和Ctrl-T 转到任何自动完成你到任何文件，快速键入，成员。使人敬畏的除了当我忘记 - 或者当我不太肯定我正在寻找的名字。项目导航仍然很重要。javascript

有时在一个项目工做时，我彷佛有30个或更多的文件打开，试图找到另外一个新的文件打开在解决方案一般最终是一个精神锻炼 - “我在哪里放这个东西？”这是一些犹豫，倾向阻止工做流程的频繁发生。css

为了使客户端框架和脚本的NuGet软件包变得更糟，将资料转储到一般不使用的文件夹中。我历来没有在MVC中的“内容”文件夹的粉丝，这只是一个空白的层，不能用于不少目的。这一般是我在每一个MVC项目中的第一件事。对我来讲，项目根是一个网站的实际内容的地方 - 是否真的须要添加另外一个文件夹来强制使用每一个资源的另外一个路径？它是丑陋的，也是低效的，由于它为您嵌入页面的每一个资源连接添加了额外的字节。html

备择方案

最近我一直在玩不一样的文件夹布局，发现移动个人奶酪实际上使得项目导航更容易。在这篇文章中，我展现了一些我发现有用的东西，也许你会发现一些这些有用的东西，或至少获得一些想法能够改变，以提供更好的项目流程。java

我一直在作的第一件事是添加一个根代码文件夹，并将全部服务器代码放入。我将Web项目根文件夹视为Web根文件夹的大粉丝，因此全部内容来自根，而不须要像Content文件夹那样进行嵌套。经过将全部服务器代码移出根树（代码除外），当您删除Controllers，App_Start，Models等并将其移动到代码下方时，根树将当即变得很干净。是的，这为服务器代码添加了另外一个文件夹级别，但它只会在一个地方留下代码相关的东西，这更容易来回跳转。另外，我发现本身在服务器端代码上作得更少，并且客户端代码我想要与之分离的服务器代码。web

根文件夹自己就做为根内容文件夹。具体来讲，我有它下面的Views文件夹，以及Css和Scripts文件夹，仅用于保存通用库和全局CSS和脚本代码。创建SPA风格应用程序的这几天，我也倾向于拥有一个应用程序文件夹，在那里我保留个人应用程序特定的JavaScript文件，以及客户端SPA应用程序（如角度）的HTML视图模板。服务器

如下是一个相对较小的项目的例子：框架

目标是保持相关的东西在一块儿，因此我不会在解决方案中最终跳出来，以得到具体的项目项目。“代码”文件夹可能会引发您的一些困惑，并回到非Web应用程序项目中的App_Code文件夹的日子，可是这些天我发现本身的服务器端代码多了不少，客户端文件更多 - HTML，CSS和JavaScript。通常来讲，我一次处理一个控制器 - 一旦打开它，它一般是惟一的服务器代码，我正常工做。业务逻辑彻底在另外一个项目中生效，所以除了控制器和ViewModels以外，尚未在代码文件夹中访问不少代码。因此把这个从根本上分离出来彷佛是一个容易的胜利。ide

嵌套页面特定内容

在我现有的不少应用程序中，纯粹的服务器端的MVC应用程序可能与某些JavaScript相关联，我倾向于具备页面级的javascript和css文件。对于这些类型的页面，我实际上更喜欢存储在与父视图相同的文件夹中的本地文件。因此一般我有一个与同一个文件夹中的视图名称相同的.css和.js文件。工具

这看起来像这样：布局

为了使其工做，您还必须在/Views/web.config文件中进行配置更改，由于使用BlockViewHandler阻止访问该文件夹的内容的Views文件夹。经过将路径从*更改成* .cshtml或* .vbhtml来简化修复，以使视图检索被阻止：

< system.webServer > < handlers > < remove name = “ BlockViewHandler ” /> < add name = “ BlockViewHandler ” path = “ * .cshtml ” verb = “ * ”
preCondition = “ integratedMode ”
type = “ System.Web.HttpNotFoundHandler ” /> </ handlers > </ system.webServer >

有了这个，从你的意见里面，你能够参考这些相同的资源，以下所示：

< link href =“〜/ Views / Admin / QuizPrognosisItems.css” rel =“stylesheet”/>

和

< script src =“〜/ Views / Admin / QuizPrognosisItems.js”> </ script >

工做正常 Views文件夹中的JavaScript和CSS文件就像.cshtml文件同样部署，也能够从该文件夹引用。

这样作并不像Visual Studio那么简单，不幸的是，直接从VS IDE中获取文件嵌套是不方便的（您必须修改.csproj文件）。

然而，Mads Kristensen有一个很好的Visual Studio加载项，经过一个快捷菜单选项提供文件嵌套。使用此选项能够选择每一个“子”文件，而后将其嵌套在父文件下。在上面的状况下，我选择.js和.css文件并嵌套在.cshtml视图下。

我甚至想把controller.cs文件放到Views文件夹中，可是这可能有点太远了:-)可是，因为Visual Studio不会发布.cs文件，编译器不会关心文件的位置。有不少选择，若是你认为这将使生活更轻松，另外一个选择是帮助将相关事情组合在一块儿。

这有什么缺点吗？可能 - 若是您使用ASP.NET Bundle或Grunt / Gulp等自动化小型化/包装工具与Uglify，将脚本和css文件分组进行分组变得更加困难，由于您可能会最终查找多个文件夹而不是单个夹。可是，再次，这是一个一次性的配置步骤，易于处理，并且更少的侵入性，而后不断搜索项目中的文件。

客户端文件夹

上述屏幕截图中显示的特定项目是传统的服务器端ASP.NET MVC应用程序，大多数内容呈如今服务器端的Razor页面中。在这些页面上也有至关数量的客户端的东西 - 具体而言，这些页面中的几个是自包含的单页角度应用程序，处理1或可能2个单独的视图，我上面显示的布局真的专一于服务器端其中有Razor视图与相关的脚本和css资源。

对于以客户为中心并具备更多脚本和基于HTML模板的内容的应用程序，我倾向于为服务器组件使用相同的布局，可是客户端代码一般能够不一样地被分解。

在SPA类应用程序中，我倾向于遵循App文件夹方法，其中全部使SPA应用程序的应用程序结束于App文件夹下方。

这是我看起来像这样 - 这是一个AngularJs项目：

在这种状况下，App文件夹包含应用程序特定的js文件以及加载到此单个SPA页面应用程序中的部分HTML视图。

在具备与特定部分视图相关联的控制器的特定Angular SPA应用程序中，我更愿意保留与视图相关联的脚本文件 - 在这种状况下为Angular Js控制器 - 与实际部分。再次，我喜欢视图与视图关联的主要代码，由于90％的UI应用程序代码被写入这两个文件之间。

这种方法运行良好，但只有控制器与部分数据至关紧密。若是您有不少更小的子控制器或许多指令，视图和代码之间的对齐更加分段，这种方法开始分崩离析，您可能会更好地使用js文件夹中的单独文件夹。遵循Angular约定，您将拥有控制器/指令/服务等文件夹。

请注意，我不是说这些方式是对或错 - 这只是为我工做，为何！

与Resharper一块儿跳过项目导航

我已经在项目树中谈了一些项目导航，这是一种常见的导航方式，至少在某些时候咱们都使用，可是若是您使用像Resharper这样的工具，它具备Ctrl-T跳转到任何东西，您可使用快捷键快速浏览并自动完成搜索。

这就是Resharper跳到任何东西的样子：

Resharper的Goto Anything框容许您输入并快速搜索整个解决方案的文件，类和成员，这是经过彻底传递解决方案资源管理器，在您的项目中找到所需内容的一种很是快速而强大的方式。只要你记得使用（有时我不会），你知道你在找什么，它是迄今为止在项目中找到最快的方法。很遗憾，这种简单的搜索界面不是本机Visual Studio IDE的一部分。

工做你喜欢工做

最终，这一切都归结为工做流程以及您喜欢的工做方式，以及什么使您*更有成效。遵循预先定义的模式是很好的一致性，只要它们不会妨碍你的工做方式。Visual Studio for ASP.NET MVC中的许多默认文件夹结构在不一样的状况下进行了定义。这几天咱们处理的项目内容比ASP.NET MVC最初引入的项目内容多得多，若是项目组织不适合您的工做流程，项目组织确定是能够获得的。因此看看看什么是好的，什么能够从组织文件不一样的好处。

与ASP.NET同样多的东西，随着事物的发展和变得愈来愈复杂，我发现我最终打了一些惯例。好消息是，您没必要遵照公约，您能够自由地为您作任何事情。

即便我在这里显示的内容与会议有所不一样，我也不认为任何人都会绊倒这些相对较小的变化，即便在较大的项目中也不会当即弄明白事情的存在。可是，在打破这些惯例以前，尽管如此，若是没有一个很好的理由来打破这些惯例，或者改变不能提供改进的工做流程，那么这样作是不值得的。打破规则，但只有有可量化的好处。

您可能不一样意我在本文中选择从标准项目结构中转移的方式，但也可能会为您提供一些想法，您能够如何混合使您的现有项目流程更好一点，并使其更容易浏览为您的环境。