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

Question

我目前正在评估 杜兰达尔 用于企业 ASP.NET MVC 应用。

然而，Durandal 使用的默认约定似乎与我已经习惯的 MVC 约定相冲突。

John Papa 的 HotTowel MVC 模板很棒，但这似乎也“废除”了 MVC 约定，通过将东西放在 App 文件夹中支持 Durandals。

我对这些约定的一些问题是:

View 可能被拆分到两个位置(/App/views 和/Views)。

脚本也分为两个位置(/App/durandal 和/Scripts)。

View 不在 RazorViewEngine 的默认 MVC 位置中。 .

我更愿意将每个元素包含在适当的 MVC 约定中，例如

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

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

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

我的问题是:

是否可以配置 Durandal 来实现上述(或类似的)？

冒险摆脱默认的 Durandal 约定是否明智？

这样做的潜在问题是什么？

Answer 1

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

是的，您可以拥有任何您想要的文件夹结构。 Durandal 不会对您的应用程序强加任何文件夹结构，但它确实具有完全可覆盖的默认约定。

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

如果您不使用路由器插件，那么您将必须自己管理模块的 uri，这可以通过遵循 requirejs' 来完成。约定和与 durandals 一起使用此约定 composition模块。

此外，您可以通过覆盖 viewlocators 来覆盖它如何找到要绑定(bind)到您的模块的 View 。惯例。 Durandal 提供了一种非常简单的方式来构建开箱即用的小型应用程序，但是如果您需要构建更大的应用程序，那么建议您创建自己的约定。

2. 放弃默认的 Durandal 约定是否明智？ 3. 这样做的潜在问题是什么？

因此，存在如何发现模块以及如何发现完全可覆盖的 View 的约定。我建议您覆盖这些并选择最适合您的方式。但是，至于将 durandal 放在上面列出的脚本文件夹中，我认为这不是一个好主意。

我不推荐这样做的原因是因为我将脚本文件夹视为所有非 AMD 模块的第三方脚本的位置。这是因为 Durandal 还带有 optimizer.exe这使得将所有 html/css/js (amd) 文件缩小/压缩/丑化为 1 个文件。

如果您将整个应用程序保存在一个 app 文件夹下，然后将 durandal 文件夹放在您的 app 文件夹中，那么优化器就可以正常工作，因为它位于 app/durandal/amd 文件夹中。所以，当你执行它时，它会向上遍历 2 个目录到你的 app 文件夹，然后扫描每个子文件夹以创建一个 app.build.js requirejs 优化文件.. 然后它将为您将整个应用程序压缩为一个文件。

这比每次向项目中添加新文件时都必须手动编辑 app.build.js 文件要好。当然..还有其他工具也可以做到这一点..但是您将不得不花时间学习他们的api以及如何配置它们。如果您不想花时间学习 grunt 之类的东西那么这个优化器很糟糕。就个人而言，我喜欢双击某些东西并为我构建整个应用程序的能力。

至于将所有非 amd 的第三方库放在单独的脚本文件夹中，我会考虑像使用 MVC's bundling 那样单独压缩这些库。 .我将它们单独捆绑的原因是因为您知道这些文件经常更改，并且如果您将它们捆绑到单独的 js 文件中，它们可以由浏览器单独缓存。而如果您的水疗中心正在改变，它可能会改变......然后您希望浏览器单独缓存它，因此它只需要重新下载您的压缩应用程序。