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

愈來愈多的我發現本身在個人一些較大的Web項目中丟失了文件。有不少內容要處理 - HTML視圖，幾個派生CSS頁面，頁面級CSS，腳本庫，應用程序範圍的腳本和頁面特定的腳本文件等等。幸運的是，我使用Resharper和Ctrl-T 轉到任何自動完成你到任何文件，快速鍵入，成員。使人敬畏的除了當我忘記 - 或者當我不太肯定我正在尋找的名字。項目導航仍然很重要。

有時在一個項目工做時，我彷佛有30個或更多的文件打開，試圖找到另外一個新的文件打開在解決方案一般最終是一個精神鍛鍊 - 「我在哪裏放這個東西？」這是一些猶豫，傾向阻止工做流程的頻繁發生。

爲了使客戶端框架和腳本的NuGet軟件包變得更糟，將資料轉儲到一般不使用的文件夾中。我歷來沒有在MVC中的「內容」文件夾的粉絲，這只是一個空白的層，不能用於不少目的。這一般是我在每一個MVC項目中的第一件事。對我來講，項目根是一個網站的實際內容的地方 - 是否真的須要添加另外一個文件夾來強制使用每一個資源的另外一個路徑？它是醜陋的，也是低效的，由於它爲您嵌入頁面的每一個資源連接添加了額外的字節。

備擇方案

最近我一直在玩不一樣的文件夾佈局，發現移動個人奶酪實際上使得項目導航更容易。在這篇文章中，我展現了一些我發現有用的東西，也許你會發現一些這些有用的東西，或至少獲得一些想法能夠改變，以提供更好的項目流程。

我一直在作的第一件事是添加一個根代碼文件夾，並將全部服務器代碼放入。我將Web項目根文件夾視爲Web根文件夾的大粉絲，因此全部內容來自根，而不須要像Content文件夾那樣進行嵌套。經過將全部服務器代碼移出根樹（代碼除外），當您刪除Controllers，App_Start，Models等並將其移動到代碼下方時，根樹將當即變得很乾淨。是的，這爲服務器代碼添加了另外一個文件夾級別，但它只會在一個地方留下代碼相關的東西，這更容易來回跳轉。另外，我發現本身在服務器端代碼上作得更少，並且客戶端代碼我想要與之分離的服務器代碼。

根文件夾自己就做爲根內容文件夾。具體來講，我有它下面的Views文件夾，以及Css和Scripts文件夾，僅用於保存通用庫和全局CSS和腳本代碼。創建SPA風格應用程序的這幾天，我也傾向於擁有一個應用程序文件夾，在那裏我保留個人應用程序特定的JavaScript文件，以及客戶端SPA應用程序（如角度）的HTML視圖模板。

如下是一個相對較小的項目的例子：

目標是保持相關的東西在一塊兒，因此我不會在解決方案中最終跳出來，以得到具體的項目項目。「代碼」文件夾可能會引發您的一些困惑，並回到非Web應用程序項目中的App_Code文件夾的日子，可是這些天我發現本身的服務器端代碼多了不少，客戶端文件更多 - HTML，CSS和JavaScript。通常來講，我一次處理一個控制器 - 一旦打開它，它一般是惟一的服務器代碼，我正常工做。業務邏輯徹底在另外一個項目中生效，所以除了控制器和ViewModels以外，尚未在代碼文件夾中訪問不少代碼。因此把這個從根本上分離出來彷佛是一個容易的勝利。

嵌套頁面特定內容

在我現有的不少應用程序中，純粹的服務器端的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同樣多的東西，隨着事物的發展和變得愈來愈複雜，我發現我最終打了一些慣例。好消息是，您沒必要遵照公約，您能夠自由地爲您作任何事情。

即便我在這裏顯示的內容與會議有所不一樣，我也不認爲任何人都會絆倒這些相對較小的變化，即便在較大的項目中也不會當即弄明白事情的存在。可是，在打破這些慣例以前，儘管如此，若是沒有一個很好的理由來打破這些慣例，或者改變不能提供改進的工做流程，那麼這樣作是不值得的。打破規則，但只有有可量化的好處。

您可能不一樣意我在本文中選擇從標準項目結構中轉移的方式，但也可能會爲您提供一些想法，您能夠如何混合使您的現有項目流程更好一點，並使其更容易瀏覽爲您的環境。