.NET MVC или SPA + WebAPI?
Alex A.
В последнее время всё чаще возникает вопрос - что выбрать MVC или SPA и WebAPI?
С одной стороны - у нас достаточно много бизнес-логики, которую легче организовывать на стороне сервера, используя языки явной типизации.
С другой стороны - на клиенте часто есть потребность в обновлении данных, добавлении / удалении стандартных блоков, изменении количества закладок или строк в таблицах. Эти операции вполне могут быть воспроизведены с помощью системы привязок (binding) и массивами, например в Angular. Однако, если связываться с Angular, то придётся переписывать всю страницу, отказываясь от уже написанных представлений на MVC, и писать новые представления на Angular. Можно, конечно, использовать Angular только в новых страницах. Тогда все что будут делать контроллеры в MVC - это тупо возвращать представление с Angular, а Angular уже будет обращаться к WebAPI, где и будет исполняться бизнес-логика. Но тогда появиться потребность в организации части бизнес-логики и на клиенте, что может быть не так просто, используя языки неявной типизации, да и теряется однородность архитектуры / подхода к организации кода.
Я, конечно, понимаю, что вопрос достаточно спорный и есть много приверженцев как одного, так и другого способов организации кода. Но меня интересуют все мнения и все "за" и "против", как одного так и другого способов.
Буду рад вашим комментариям и надеюсь они помогут мне понять, где проходит тонкая грань между двумя подходами.
Заранее, благодарен.
Alexander Byndyu
--
---
Вы получили это сообщение, поскольку подписаны на группу dotnetconf.
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+unsubscribe@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.
Artur Drobinskiy
Alex A.
Александр, как я понял из вашей статьи, вы не очень верите в full-stack разработчиков, точнее в их возможность делать одинаково хорошо работу на сервере и на клиенте.
Я, скорей всего, склонен принять вашу точку зрения. Однако, появляется вопрос, не связанный с темой "MVC или WebAPI", но напрашивающийся после прочтения вашей статьи.
Почему тогда не использовать JavaScript и на сервере тоже, например Node.js? Тогда можно сократить команду на всех C# разработчиков и использовать только сильных разработчиков JavaScript.
Alexander Byndyu
Alex A.
Тогда ещё один вопрос по теме - что выбрать WebAPI или Node.js? При этом допустим, что команда не набрана и проект средней степени сложности.
Заранее благодарен.
Alexander Byndyu
--
---
Вы получили это сообщение, поскольку подписаны на группу dotnetconf.
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.
Чапаев
Alexander Byndyu
--
---
Вы получили это сообщение, поскольку подписаны на группу "dotnetconf".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Alex A.
@Александр, если я правильно вас понял, то вы переносите бизнес логику на клиента, оставляя "тонкий" сервер, служащий api-прослойкой для обращения к базам данных. Однако, существует предел сложности для слабо-типизированных языков, таких как javascript, перейдя который, становится тяжело поддерживать и развивать проект. ИМХО, у языков с более строгой типизацией предел сложности намного выше, что позволяет, в свою очередь, делать более сложные проекты, прилагая меньше усилий. Вопрос, как определить этот предел?
У нас в проекте вся корпоративная бизнес-логика реализована на стороне сервера на языках C# и C++, клиент отвечает только за представление. Да у нас есть сложные представления, которые сами требуют логику, но это логика представления и ничего более. К сожалению, многие представления (и сложные в том числе) у нас написаны на .net mvc с поддержкой jquery. Это вызывает много перезагрузок страниц, там где это не нужно. По-этому мы пришли к мнению, что представления со сложным ux/ui, легче превратить в spa.
Однако, такое решение меня немного смущает, так как появляется два вида маршрутов: один - это стандартная .net mvc маршрутизация, второй - это spa/angular маршрутизация. Такой вариант прозрачен для пользователей, но не прозрачен для поисковых движков, а значит не вариант :)
С другой стороны у нас нет сильных фронт-эндов в команде, а следовательно, как сказал @Чапаев, проект может затормозиться. Но если дела обстоят таким образом, то и переход на spa + web api не представляется таким уж решением проблемы. Значит вопрос остаётся открытым...
Alexander Byndyu
@Александр, если я правильно вас понял, то вы переносите бизнес логику на клиента, оставляя "тонкий" сервер, служащий api-прослойкой для обращения к базам данных.
у языков с более строгой типизацией предел сложности намного выше
но это логика представления и ничего более
у нас нет сильных фронт-эндов в команде, а следовательно, как сказал @Чапаев, проект может затормозиться
--
---
Вы получили это сообщение, поскольку подписаны на группу dotnetconf.
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+unsubscribe@googlegroups.com.
Denis Kodua
Чапаев
четверг, 19 октября 2017 г., 15:35:17 UTC+3 пользователь Alex A. написал:
С другой стороны у нас нет сильных фронт-эндов в команде, а следовательно, как сказал @Чапаев, проект может затормозиться. Но если дела обстоят таким образом, то и переход на spa + web api не представляется таким уж решением проблемы. Значит вопрос остаётся открытым...
люди обычно выворачивались через функцию ajax jquery. но то тупиковый путь честно говоря. я поэтому писал о ReactJS. это не framework как ангуляр, осваивать будет проще. но асинхронное взаимодействие реализовать позволит.
то есть на страницах, где вы видите необходимость реализации SPA подхода можно использовать ReactJS, на остальных - mvc подход.
я во всяком случае в таком направлении думаю.
Alex A.
С уважением, Саша.