Aspnetcore: MVC слишком сложен для использования?

Если вы не являетесь поклонником ORM (сопоставителей отношения объектов), таких как EntityFramework, вы можете написать SQL вручную, используя ADO.NET. Вы также можете использовать легкий ORM, такой как Dapper , который не генерирует запросы (вы можете написать их вручную). В EntityFramework также есть метод ExecuteSQL, который при необходимости дает вам больше контроля (https://docs.microsoft.com/en-us/ef/core/querying/raw-sql).

Кроме того, если MVC выглядит слишком сложным для простых страниц, попробуйте Razor Pages.

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

Что касается простоты по сравнению с веб-формами, могу ли я напомнить вам о несчастье viewstate, runat=server и, боже, упаси нас всех от жизненного цикла страницы.
С уважением

Это смешно.

Мне кажется довольно простым.

Кроме того, если MVC выглядит слишком сложным для простых страниц, попробуйте Razor Pages.

Только что закончил проект миграции WebForms -> RazorPages. Честно говоря, это мог быть просто MVC, но определенно хороший вариант для небольших веб-сайтов, ориентированных на страницы. В проектах MVC я считаю, что слишком много «охотюсь» за кодом, т.е. постоянно перескакивая с представления на контроллер, прокручивая множество действий, тогда как в RazorPages я просто иду прямо к PageModels.

Я ненавижу раздутый EF — Dapper намного проще, особенно если использовать его с чем-то вроде Dapper.FastCRUD.

Не только у тебя @LJ9999 , у MVC и любого фреймворка нет ответов на все вопросы. Это может быть не лучшая структура, подходящая для вашего проекта, и она может не соответствовать тому, как вы думаете. Не нужно пытаться вставить квадратные колышки в круглые отверстия, если только вы не любите самонаказание.

MVC — один из ваших вариантов. Оцените несколько различных подходов и выберите наиболее подходящий для вас. Найдите что-то, что имеет для вас смысл. Найдите (или сделайте) то, в чем вы наиболее продуктивны. Не ведитесь на то, что популярно. Популярность не всегда связана с заслугами, и даже то, что является заслугой в одном случае, не работает в другом месте.

Итак, позвольте мне присоединиться к вам и скептически относиться к наиболее распространенным способам выполнения задач. Скептически относиться к подходу, которого придерживаются все, и критически мыслить для себя — хорошее начало. Если вы думаете, что можете добиться большего, вы, вероятно, сможете. Действуй!

Для любого читающего, кто чувствует это как нападение на них и их избранный популярный путь, это действительно не нападение на вас. Это говорит найти то, что работает для вас. Так что это просто заявление о том, что, хотя все компьютеры могут работать на одном и том же языке, человеческий разум — нет. Все люди разные, и это здорово.

+1 к щеголеватому, используй его.

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

Похоже, вы можете больше не принимать во внимание его использование в примере. Ответом на этот вопрос является целевая аудитория: в 2019 году больше людей разбираются в парадигмах ORM, чем на самом деле разбираются в SQL. SQL не умер, просто у него очень сильная конкуренция с высоким проникновением в контингент молодых разработчиков.

Как человек, который прошел через каждую итерацию Asp.Net и MVC до того, что мы имеем сейчас с Asp.Net Core, я могу сказать вам, что отладка ошибок жизненного цикла страницы и попытка создать что-либо относительной сложности с помощью веб-форм было кошмаром по сравнению с к МВК. Веб-формы скрывают большую часть фактической работы за тем, что кажется волшебным. Он абстрагирует весь способ работы веб-запросов, пытаясь держать вас за руку и притворяться, что сеть не лишена состояния. Он лжет вам и говорит, что вы красивы и что ваша попа хорошо выглядит в этих джинсах. Это ложно укрепляет вашу уверенность и делает веб-технологии нечеткими. И вы в блаженстве продолжаете свой день, думая, что если вы можете создать веб-страницу с формой на ней и сохранить ее в таблице, то вы сможете делать что угодно. Пока вы не получите это новое требование для создания пользовательской динамической формы. Или заставить что-то работать с этим конкретным фреймворком на стороне клиента, потому что клиент думает, что это красиво. Вы понимаете, что теперь работаете против течения, и удивляетесь, как это делают все остальные.
MVC — это не ракетостроение, это проверенный шаблон, который развился в сообществе разработчиков после осознания того, что «должен быть лучший способ» и многих лет втыкания круглых колышков в квадратные отверстия. Если вы думаете, что это сложно, это, вероятно, потому, что вы не столкнулись ни с одной из проблем, которые он должен решать, и вы не потратили достаточно времени на решение сложных проблем. Начните с более простых руководств, если это слишком сложно.
Если вы решите, что это не для вас, всегда есть PHP или NodeJs.

Для чего-то большего, чем тривиальное соединение, я бы просто использовал ExecuteSQL EF. Я действительно думаю, что вы можете недооценить сложность, которую он может пытаться представить, потому что у него нет способа логического именования таблиц соединения, и ему может потребоваться гибкость при назначении офиса. Если вам не нравится EF, вы не одиноки. Большинство людей, использующих MVC, вероятно, не используют EF. Одно не требует другого.

Лично я нахожу веб-формы намного более сложными, чем MVC, потому что у них так много сложной логики событий, что скрывает то, что на самом деле является циклом ответа на запрос. MVC для тех, кто никогда об этом не задумывался, поначалу будет сложно, потому что это другая модель организации, но после многих лет использования индустрия, похоже, решила, что MVC на самом деле проще в долгосрочной перспективе. Это всего лишь вопрос предпочтений, но открытие такого билета на технологию, которая была популярной в течение многих лет, — это просто выход.

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

ОМГ, я сейчас так смеюсь.

Слушай, приятель, если это кажется слишком сложным или сложным, отойди от него и используй что-нибудь другое. Никто не держит пистолет у твоей головы, верно?

Некоторые из нас были вокруг квартала несколько раз и предпочитают простоту asp mvc веб-формам, потому что нам приходилось иметь дело с ужасной кучей непроверяемого спагетти-кода, который выходит из монолитных монстров веб-форм.

А если серьезно, если вам нравятся веб-формы, и кто-то готов платить вам за кодирование веб-форм, тогда делайте это! И перестань ныть о вещах, в которых не разбираешься.

Это сатирический пост? Не знаю, на реддите или на гитхабе...

Я работал над разработкой ERP под веб-формы Asp.net и Asp.net MVC для двух разных систем, могу с уверенностью сказать, что работа над веб-формами — это пытка, особенно когда у тебя огромное решение с плохой архитектурой, и наоборот MVC может волшебным образом превратить уродливую архитектуру в решение высшего уровня с возможностью организации слоев и использования шаблона репозитория с надежной ORM, такой как EF.
но, честно говоря, большинство разработчиков, которых я встречал и которые жалуются на MVC, страдают от ограниченного опыта и знаний о новом шаблоне.
Я лично советую разработчикам, которые хотят изучить MVC с нуля до героя, попробовать https://www.pluralsight.com вместо того, чтобы путешествовать по сети и тратить время и деньги на спорные темы и блоги о MVC, которые во многих случаях являются предвзятыми или плохими. в контексте.

Вау, это время разработчиков изменений на самом деле верно. Я похвалил Microsoft за то, насколько простыми и понятными были EF и MVC, когда я впервые столкнулся с ними в 2013 году. Как уже было сказано, понимание этих фреймворков не происходит автоматически! Следуйте инструкциям, посмотрите несколько из сотен видео и попробуйте еще раз. Прости, чувак, но у тебя появляется понимание этих вещей, когда ты проводишь с ними время.

Я согласен с автором. Для тех, кто впервые использует mvc. Подход не такой дружелюбный, как другие, такие как php, rail ... слишком много концепции, чтобы понять ее, прежде чем использовать. Однако, как только вы поняли концепцию, mvc кажется очень эффективным.

Почему кто-то ненавидит фреймворк сущностей. За последние три года мне приходилось писать не более 5 SQL-запросов.

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

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

Некоторые образцы:
https://github.com/dotnet/docs/issues/9115
https://github.com/dotnet/docs/issues/9299
https://github.com/dotnet/docs/issues/9274
https://github.com/dotnet/docs/issues/9234
https://github.com/MicrosoftDocs/azure-docs/issues/20313
https://github.com/dotnet/docs/issues/9396
https://github.com/aspnet/EntityFramework6/issues/671
https://github.com/aspnet/EntityFramework6/issues/686
https://github.com/twbs/bootstrap/issues/27783
https://github.com/MicrosoftDocs/visualstudio-docs/issues/2237
https://github.com/aspnet/EntityFramework.Docs/issues/1254
https://github.com/aspnet/EntityFramework.Docs/issues/1240

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

Похоже, ваши проблемы связаны не с MVC, а с Entity Framework. Для некоторых из нас, которым удобно писать SQL, Entity Framework добавляет нежелательный уровень абстракции. Лично я использую Dapper, который значительно упрощает использование Readers. Вы все еще можете написать свой собственный SQL. MVC — довольно простой шаблон. Становится немного сложнее понять, как передавать данные и как эффективно использовать некоторые вспомогательные функции, но концептуально это несложно.

MVC не требует использования EF, хотя встроенная аутентификация пользователей использует его.

Друзья, комментируйте с помощью или позитивом, но не с насмешками. У ОП, похоже, есть опасения по поводу EF, и комментарий Дэвида превосходен. https://github.com/aspnet/AspNetCore/issues/7039#issuecomment-457869924

Вопросы - это место, где можно помочь. Если вы хотите поспорить о достоинствах MVC по сравнению с чем-то другим, попробуйте один из других популярных сайтов для жалоб в Интернете.

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

Я полностью согласен с тем, что веб-разработка / разработка программного обеспечения сложны. Лично я провел годы, изучая и экспериментируя, чтобы получить опыт, который у меня есть. Каждый раз, когда я хочу использовать новый фреймворк или библиотеку, это все еще сложно. Это требует, чтобы я тратил больше времени на изучение и эксперименты, чтобы чувствовать себя комфортно и уверенно использовать его. Поскольку с годами я узнавал все больше и больше, я искренне верю, что стал лучше и быстрее учиться, поэтому мне становится легче.
С годами, я думаю, связанные с этим проблемы изменились. Кое-что стало проще, однако появились и новые задачи. В целом, однако, я считаю, что сейчас это намного проще по сравнению с тем, когда я начинал. Я также думаю, что это менее разочаровывающий опыт, и я нахожу его более приятным.
Сказав все это, я думаю, что как отрасль мы всегда можем продолжать стремиться к лучшему. Я думаю, что подобные вопросы подчеркивают проблемы, с которыми мы сталкиваемся, и вдохновляют на необходимость дальнейшего улучшения ситуации.

Я хочу быть особенно осторожным и не советовать вам выбирать одно решение вместо другого, потому что я не верю, что у меня достаточно информации для этого.
Одна из самых больших проблем, с которыми я сталкиваюсь при решении проблем, — это определение реальной решаемой проблемы. Было бы очень легко классифицировать эту проблему как необходимость «создать веб-сайт», однако с таким количеством решений для выбора «создания веб-сайта» любое из них потенциально может работать. Проблема должна быть разбита как можно больше, потому что это обеспечивает критерии для оценки различных решений.
Во-вторых, у всех нас есть личные предпочтения. Вы имеете право на свое собственное, и никто не может сказать вам, что вы предпочитаете или с чем вам удобнее работать. Это полностью зависит от вас.
Кроме того, когда в процесс вовлечены другие лица, команда или компания, может потребоваться рассмотрение дополнительных факторов, таких как предпочтения команды, а также политика и стратегия компании.
Это лишь некоторые из факторов, которые необходимо учитывать при оценке различных решений.

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

Я надеюсь, что этот ответ поможет в некотором роде. Просто знайте, что есть много людей, которые готовы помочь, однако вы несете ответственность за то, чтобы кому-то было легко помочь вам.

@ LJ9999 один (надеюсь, конструктивный) комментарий...

Судя по опубликованному вами SQL, возможно, вы используете Entity Framework 6. Entity Framework Core (более новая версия, написанная с нуля) имеет явную цель создания разумного, удобочитаемого SQL, который пытается походить на то, что вы написали бы сами - есть очень хороший шанс, что если вы попробуете это, вы увидите что-то более разумное - попробуйте и дайте нам знать.

Мой итоговый критерий прост... Количество строк кода для реализации. Больше кода — больше риск ошибок, более длинная кривая обучения, больше потерянных часов (если вы не подрядчик с почасовой оплатой).
Я видел в 8 раз больший объем кода при выполнении mvc с инфраструктурой Javascript. По сравнению со страницами cshtml старой школы. И в 5 раз больше времени.

Остерегайтесь тех, кто использует фразу «правильный путь»

В этом случае вам больше поможет MVC как программная архитектура.
M — это модель, которая может быть вашей базой данных, она может отвечать на запросы информации, отвечать на инструкции по изменению состояния своей информации и даже уведомлять наблюдателей в управляемых событиями системах при изменении информации.
V — это представление, которое эффективно обеспечивает элемент пользовательского интерфейса приложения. Он преобразует данные из модели в форму, подходящую для пользовательского интерфейса.
C — это контроллер, который получает пользовательский ввод и вызывает объекты модели или просто визуализирует представление.

Ваш выбор технического стека не означает, что MVC хорош или плох, это просто программная архитектура.

@шансельман

Друзья, комментируйте с помощью или позитивом, но не с насмешками. У ОП, похоже, есть опасения по поводу EF, и комментарий Дэвида превосходен. #7039 (комментарий)

Я полностью согласен со Скоттом.

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

Это может помочь изменить заголовок, чтобы он соответствовал реальной проблеме.

Мы периодически закрываем «дискуссионные» вопросы, которые не обновлялись в течение длительного периода времени.

Приносим свои извинения, если это причиняет неудобства. Мы просим, ​​чтобы, если вы все еще сталкиваетесь с проблемой, пожалуйста, зарегистрируйте новую проблему с обновленной информацией, и мы проведем расследование.