Архитектор ASP.NET MVC с полимером

Я создал уже 3 приложения с использованием ASP.NET MVC и Polymer, но я всегда получаю ту же архитектурную проблему.Архитектор ASP.NET MVC с полимером

На данный момент, если я хочу, чтобы отделили MVC Просмотров от веб-компоненты Polymer я в конечном итоге со структурой, как этот:

- wwwroot 
    - bower_components (polymer) 
    - elements (my components) 
- View (my views) 
- Controllers (my controllers)

Тогда, если я должен разрешить конкретный вид, для пример: http://mydomain/home/index я в конечном итоге что-то вроде:

- Controller > Home 
- Action > Index 
- View > Index.cshtml 
- Element > paper-page-index.html

и от моего Index.cshtml

<!-- import the element --> 
<link rel="import" href=".../paper-page-index.html" /> 
<!-- render the element and pass properties --> 
<paper-page-index first-name="@Model.FirstName"></paper-page-index>

Проблема в том, что я должен передать каждое отдельное свойство моего ViewModel в пользовательский элемент, который становится очень многословным и иногда даже скучным. Каким должен быть правильный путь? Каждое представление .cshtml должно рассматриваться как веб-компонент и перестать создавать веб-компоненты как таковые и включать их в мои .cshtml-страницы? Или у меня есть два метода GET, как Мартин Фаулер говорит:

один GET, чтобы получить мой взгляд (Controller/Action/.cshtml страница)
один GET для извлечения ViewModel из MVC

Также моя логика представления должна быть только в мои элементы Полимера или также в мои C# ViewModels?

Любой ключ?

источник

2017-02-20 Raffaeu

Возможно, вам нужно просто свернуть MVC и использовать Polymer в качестве слоя с вашим приложением SPA. C# для внешнего интерфейса, Polymer для интерфейса. Это будет более чистая и еще более удобная архитектура. Я бы даже предложил хранить код в виде двух разных репозиториев (frontend, api). – sed

На самом деле это уже так, что вы подразумеваете под API - это интерфейс (api), API, используемый для создания модели представления, а не для модели данных. Но я все еще хочу использовать некоторые функции ASP.NET MVC, такие как идентификатор ASP.NET, маршрутизация. Вот почему я смешиваю двух ребят вместе – Raffaeu

В основном, что я говорю, это: Отметьте представления из MVC, используйте его как чистый API. Удалите все папки wwwroot и Views. На самом деле - запуск проекта только по API. Или даже лучше, используйте .NET Core. – sed

В конце концов, я решил архитектор проект следующим образом:

Back-конец

ядра asp.net
контроллеров разоблачающих методы REST
прикрепленный с помощью жереха .net

Фронтальный

asp.net ядро для "интерфейсными APIs"
стандарт "статические страницы" для полимеров
стандартные "элементы" структура полимера рассматривает

A View предоставляется «как есть», а затем запрашивает «front end» apis соответствующую модель представления. Затем он запрашивает конечную точку HTTP REST, если она требует данных из хранилища данных/lucene.

Это представление архитектуры архитектуры «двух шагов» М.Фаулер, объясняется здесь: https://martinfowler.com/eaaCatalog/twoStepView.html

Преимущества

Я все еще может обеспечить весь передний конец статического контента с помощью ASP.NET Идентичность и OAuth
я могу воспользоваться Polymer строить, потому что есть не строгая связь между Polymer и Razor
Я могу полностью отделить пользовательский интерфейс, презентационную логику и бизнес-логику в 3 разных областях.

источник

2017-02-23 08:15:56 Raffaeu

ответ

Смежные вопросы