Соглашения Дюрандала и ASP.NET MVC

В настоящее время я оцениваю Durandal для использования в корпоративном приложении ASP.NET MVC.

Однако соглашения по умолчанию, используемые Durandal, похоже, противоречат соглашениям MVC, к которым я привык.

Шаблон HotTowel MVC от John Papa замечателен, но это тоже кажется "покончить" с конвенциями MVC в пользу Durandals, поместив вещи в папку приложения.

Несколько проблем, которые я имею с этими соглашениями, заключаются в следующем:

  • Представления потенциально разделены на два местоположения (/App/views и /Views ).
  • Сценарии также разбиваются на два местоположения (/App/durandal и /Scripts ).
  • Представления не находятся в местоположениях MVC по умолчанию для RazorViewEngine.

Я бы предпочел сохранить каждый элемент, содержащийся в соответствующих соглашениях MVC, например.

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

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

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

Мои вопросы:

  • Можно ли настроить Durandal для достижения вышеуказанного (или чего-то подобного)?

  • Насколько разумно отказаться от стандартных дюрандальных соглашений?

  • Каковы потенциальные проблемы при этом?

Ответы

Ответ 1

1. Можно ли настроить Durandal для достижения вышеуказанного (или чего-то подобного)?

Да, у вас может быть любая структура папок, которую желает ваше сердце. Durandal не накладывает никакой структуры папок на ваше приложение, но у него есть соглашение по умолчанию, которое полностью переоценивается.

Если вы используете Durandals router, вам нужно посмотреть, как настроить его для поиска модулей. Есть много способов сделать это, я предпочитаю создавать свое собственное соглашение, переопределяя router.autoConvertRouteToModuleId.

Если вы не используете плагин router, вам придется самостоятельно управлять uris для своих модулей, и это делается, следуя requirejs ' и используя это соглашение по модулю w/durandals composition.

Кроме того, вы можете переопределить, как он находит представления для привязки к вашим модулям, переопределяя соглашение viewlocators. Durandal обеспечивает очень упрощенный способ структурирования небольших приложений прямо из коробки, но если вам нужно создавать более крупные приложения, рекомендуется создать собственные соглашения.

2. Разве разумно отважиться от стандартных дюрандальных конвенций? 3. Каковы потенциальные проблемы при этом?

Итак, существуют соглашения о том, как открывать модули и как открывать полностью видимые виды. И я рекомендую вам переопределить их и выбрать способ, который лучше всего подходит. Но, поскольку для размещения durandal внутри вашей папки сценариев, как вы указали выше, я не думаю, что это хорошая идея.

Я не рекомендую это, потому что я вижу папку сценариев в качестве места для всех ваших сторонних скриптов, которые являются модулями NON-AMD. Это связано с тем, что Durandal также поставляется с optimizer.exe, который позволяет минимизировать/сжать/убрать все ваши файлы html/css/js (amd) в 1 файл.

Если вы сохраняете все приложение в папке приложения, а затем сохраняете папку durandal внутри папки приложения, оптимизатор работает только потому, что он находится внутри папки app/durandal/amd. Таким образом, когда вы его выполнили, он перекроет до 2 каталогов в вашу папку приложений и затем сканирует каждую подпапку, чтобы создать файл app.build.js для оптимизации. то он сжимает ваше приложение в один файл для вас.

Это приводит к необходимости вручную редактировать файл app.build.js каждый раз, когда вы добавляете новый файл в свой проект. Конечно.. есть и другие инструменты, которые могут сделать это тоже.., но вам придется потратить время на изучение их api и как их настроить. Если вы не хотите посвятить время изучению чего-то вроде grunt, то этот оптимизатор - это задница. Лично мне нравится возможность просто дважды щелкнуть что-то и создать для меня все мое приложение.

Что касается размещения всех ваших сторонних библиотек, которые являются не-amd в отдельной папке скриптов, я бы рассмотрел их сжатие, используя набор MVC. Причина, по которой я буду связывать их отдельно, состоит в том, что вы знаете, что эти файлы arnt меняются очень часто, и если вы свяжете их с отдельными js файлами, они могут быть кэшированы браузером отдельно. Принимая во внимание, что если ваш спа изменяется, что он, вероятно, будет... тогда вы хотите, чтобы браузер кешировал это отдельно, поэтому ему нужно только повторно загрузить сжатое приложение.

Ответ 2

Что мы делаем (это то, что я видел, Роб тоже делает) заключается в том, что создавать папки внутри папки /App в зависимости от функциональных областей приложения. Затем просто создайте представление и просмотрите файл модели внутри этих папок.

Trick должен иметь свойство "viewUrl" в каждой модели представления, чтобы указать durandal, который используется для просмотра. Такой способ структурирования приложения полезен для крупных проектов, где имеется много видов/моделей просмотра; избегает путаницы, когда ваш проект растет.

define(['durandal/app', 'durandal/system', 'plugins/router'],
    function (app, system, router) {
        var vm = {
            viewUrl: 'myfolder/myview.html',
        };
        return vm;
    }
);

Вы все еще можете использовать viewLocator.useConvention(); когда вы загружаете приложение; durandal все равно найдет представление, пока у вас есть свойство viewUrl.