asp.net-mvc – Durandal和ASP.NET MVC约定

我正在评估Durandal用于企业ASP.NET MVC应用程序.

然而,Durandal使用的默认约定似乎与我习惯的MVC约定相冲突.

John Papa的Hottowel MVC模板是非常好的,但是这也似乎是通过将东西放在App文件夹中来“脱离”MVC约定以支持Durandals.

我与这些惯例的几个问题是：

>视图可能会分割在两个位置(/ App / views和/ Views).
>脚本也分为两个位置(/ App / durandal和/ Scripts).
>视图不在RazorViewEngine的默认MVC位置.

我宁愿将每个元素保存在适当的MVC约定中,例如

/Controllers/
---- HomeController
---- AdminController

/Scripts/    
---- durandal/    
---- viewmodels/    
-------- Home
-------- Admin

/Views/    
---- Home    
---- Admin

我的问题是：

>是否可以配置Durandal以实现上述(或类似的东西)？
冒险脱离默认的Durandal惯例是明智的吗？
>这样做有什么潜在的问题？

解决方法

1.是否可以配置Durandal以实现上述(或类似的东西)？

是的,你可以有任何你想要的文件夹结构. Durandal不会对应用程序施加任何文件夹结构,但它的默认约定完全可以覆盖.

如果您使用的是Durandals router,那么您将需要查看如何配置它来查找模块.有很多方法可以做到这一点,我更喜欢通过覆盖router.autoConvertRoutetoModuleId来创建自己的约定.

如果您没有使用路由器插件,那么您将不得不自己管理您的模块的uris,这是按照requirejs’惯例完成的,并且沿着w / durandals composition模块使用此约定.

此外,您可以覆盖如何通过覆盖viewlocators约定找到要绑定到模块的视图. Durandal提供了一种非常简单的方法来构建小型应用程序,但是如果您需要构建更大的应用程序,那么建议您创建自己的约定.

逃避违反Durandal惯例的明智之举吗？这样做有什么潜在的问题？

所以,有如何发现模块和如何发现完全可以覆盖的视图的约定.我建议你重写这些,并选择最适合你的方法.但是,至于在上面列出的脚本文件夹中放置durandal,我不认为它是一个好主意.

我不推荐这个的原因是因为我将脚本文件夹看作是所有第三方脚本是非AMD模块的地方.这是因为Durandal还附带了一个 optimizer.exe,它将所有您的html / css / js(amd)文件缩小/压缩/ ugll化为1个文件.

如果您将整个应用程序保留在应用程序文件夹下,然后将durandal文件夹保存在应用程序文件夹中,则优化程序仅适用于应用程序/ durandal / amd文件夹中.所以,当你执行它,它会横跨2个目录到你的应用程序文件夹,然后扫描每个子文件夹,以创建一个 app.build.js requirejs优化文件..然后它将压缩您的整个应用程序到一个文件为您.

每次向项目添加新文件时,都必须手动编辑app.build.js文件.当然..还有其他的工具,可以做到这一点..但你必须花时间学习他们的api和如何配置它们.如果你不想花时间学习像grunt这样的东西,那么这个优化器就是踢屁股.就个人而言,我喜欢只需双击某些东西,并为我建立整个应用程序的能力.

至于将所有不安全的第三方库放在一个单独的脚本文件夹中,我会像使用MVC’s bundling那样单独压缩这些库.我将捆绑这些单独的原因是因为你知道这些文件经常变化,如果你捆绑那些进入一个单独的js文件,它们可以被浏览器单独缓存.而如果您的水疗中心正在更改,那么它可能会..那么您希望浏览器单独缓存,因此只需要重新下载压缩的应用程序.

原文地址：https://www.jb51.cc/aspnet/250514.html

asp.net-mvc – Durandal和ASP.NET MVC约定

解决方法

相关推荐