Durandal 和 ASP.NET MVC 约定 [英] Durandal and ASP.NET MVC conventions
问题描述
我目前正在评估在企业 ASP.NET MVC 应用程序中使用的 Durandal.
I'm currently evaluating Durandal for use in an enterprise ASP.NET MVC application.
然而，Durandal 使用的默认约定似乎与我已经习惯的 MVC 约定相冲突.
However the default conventions used by Durandal seem to conflict with the MVC conventions I've grown accustomed to.
John Papa 的 HotTowel MVC 模板很棒，但这似乎也废除"了 MVC 约定，通过将内容放在 App 文件夹中来支持 Durandals.
The HotTowel MVC template by John Papa is great, but this too seems to "do away" with MVC conventions in favour of Durandals by putting things in an App folder.
我对这些约定的一些问题是:
A couple of the issues I have with these conventions are:
- 视图可能会分布在两个位置(/App/views 和/Views).
- 脚本也分为两个位置(/App/durandal 和/Scripts).
- 视图不在
RazorViewEngine的默认 MVC 位置.
- Views are potentially split across two locations (/App/views and /Views).
- Scripts are also split across two locations (/App/durandal and /Scripts).
- Views are not in the default MVC locations for the
RazorViewEngine.
我希望每个元素都包含在适当的 MVC 约定中，例如
I would prefer to keep each element contained in the appropriate MVC conventions e.g.
/Controllers/
---- HomeController
---- AdminController
/Scripts/
---- durandal/
---- viewmodels/
-------- Home
-------- Admin
/Views/
---- Home
---- Admin
我的问题是:
是否可以配置 Durandal 来实现上述(或类似的)?
Is it possible to configure Durandal to achieve the above (or something similar)?
放弃默认的 Durandal 惯例是否明智?
Is it wise to venture away from the default Durandal conventions?
这样做的潜在问题是什么?
What are the potential issues in doing so?
推荐答案
1.是否可以配置 Durandal 来实现上述(或类似的)?
是的，您可以拥有自己想要的任何文件夹结构.Durandal 不会在您的应用程序上强加任何文件夹结构，但它确实有一个完全可覆盖的默认约定.
1. Is it possible to configure Durandal to achieve the above (or something similar)?
Yes, you can have any folder structure your heart desires. Durandal does not impose any folder structure on your application but it does have a default convention which is completely overridable.
如果您使用 Durandals 路由器，那么您将需要研究如何配置它以查找模块.有很多方法可以做到这一点，我更喜欢通过覆盖 router.autoConvertRouteToModuleId 来创建自己的约定.
If you are using Durandals router then you will want to look into how to configure it to find modules. There are many ways of doing this, I prefer to create my own convention by overriding the router.autoConvertRouteToModuleId.
如果您没有使用路由器插件，那么您必须自己管理模块的 uri，这可以按照 requirejs' 约定并将此约定与 durandals composition 模块一起使用.
If you are not using the router plugin then you will have to manage the uris for your modules yourself and this is done by following requirejs' convention and using this convention along w/ durandals composition module.
此外，您可以通过覆盖 viewlocators 约定来覆盖它如何找到要绑定到您的模块的视图.Durandal 提供了一种非常简单的方式来构建开箱即用的小型应用程序，但如果您需要构建更大的应用程序，则建议您创建自己的约定.
Also, you can override how it finds the views to bind to your modules by overriding the viewlocators convention. Durandal provides an very simplistic way of structuring small applications right out of the box but if you need to build larger applications then it is recommended you create your own conventions.
因此，存在如何发现模块和如何发现完全可覆盖的视图的约定.我建议您覆盖这些并选择最适合您的方式.但是，至于将 durandal 放在上面列出的脚本文件夹中，我认为这不是一个好主意.
So, there are the conventions of how to discover modules and how to discover views which are completely overridable. And I recommend you do override these and choose a way that suites you best. But, as for placing durandal inside your scripts folder as you have listed above I dont think its a good idea.
我不推荐这样做的原因是因为我将脚本文件夹视为存放所有非 AMD 模块的第三方脚本的地方.这是因为 Durandal 还附带了一个 optimizer.exe，它可以缩小/压缩/丑化所有的 html/css/js (amd) 文件合并为 1 个文件.
The reason I dont recommend this is because I see the scripts folder as a place for all your third party scripts that are NON-AMD modules. This is because Durandal also comes with an optimizer.exe which makes minifying/compressing/uglifying all your html/css/js (amd) files into 1 file.
如果您将整个应用程序保存在一个 app 文件夹下，然后将 durandal 文件夹放在您的 app 文件夹中，那么优化器就可以正常工作，因为它位于 app/durandal/amd 文件夹中.因此，当您执行它时，它将横向向上 2 个目录到您的 app 文件夹，然后扫描每个子文件夹以创建一个 app.build.js requirejs 优化文件.. 然后它会将您的整个应用程序压缩到一个文件中.
If you keep your entire application under an app folder and then have the durandal folder inside your app folder the optimizer just works because it lives inside the app/durandal/amd folder. So, when you execute it, it will transverse up 2 directories to your app folder and then scan every subfolder to create a app.build.js requirejs optimization file.. and then it will compress your entire application to one file for you.
这比每次向项目添加新文件时都必须手动编辑 app.build.js 文件好得多.当然......还有其他工具可以做到这一点......但你必须花时间学习他们的api以及如何配置它们.如果您不想花时间学习诸如 grunt 之类的东西，那么这个优化器就是一团糟.就我个人而言，我喜欢只需双击某些内容即可为我构建整个应用程序的功能.
This beats having to hand edit an app.build.js file everytime you add a new file to your project. Sure.. there are other tools out there which can do this too.. but you will have to spend time learning their api and how to configure them. If you dont feel like devoting the time to learning something like grunt then this optimizer is kick ass. Personally, I like the ability to just double click something and have my whole application built for me.
至于将所有非 amd 的第三方库放在单独的脚本文件夹中，我会考虑像使用 MVC 的捆绑.我将它们单独捆绑的原因是因为您知道这些文件不会经常更改，并且如果您将它们捆绑到单独的 js 文件中，它们可以由浏览器单独缓存.而如果您的水疗中心正在发生变化，它可能会发生变化……那么您希望浏览器单独缓存它，以便它只需要重新下载您的压缩应用程序.
As for placing all your third party libraries which are non-amd in a seperate scripts folder I would look into compressing those seperately like using MVC's bundling. The reason I would bundle those seperately is because you know those files arnt changing very often and if you bundle those into a seperate js file they can be cached by the browser seperately. Whereas if your spa is changing, which it it probably will.. then you want the browser to cache that seperately so it only has to re-download your compressed application.
这篇关于Durandal 和 ASP.NET MVC 约定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
