Как создать правильную иерархию в asp.NET Core MVC?

Question

[Nik Faraday]

Здравствуйте

Начал изучать asp.NET Core и сейчас "натягиваю" Bootstrap шаблон и я не знаю как правильно сделать иерархию файлов.
По идеи как на то и есть архитектурный паттерн MVC для того, что бы всё было по папочкам.

В шаблоне все .html страницы накинуты друг на друге и нет чёткой иерархи, по какому принципу нужно те же файлы кидать в рамках MVC проекта?

Answer 1

[V Sh.]

Если я ничего не путаю, то при создании проекта по шаблону у вас уже есть размеченная иерархия. Есть папка "Scripts" для скриптов, папка "Content" для хранения стилей. MVC - это совсем не про то, где и как хранить файлы. MVC - это про то, что все объекты и классы вы храните отдельно (по умолчанию папка "Models"), то, что вы хотите показать пользователю вы пишите также отдельно во View, а то, как View взаимодействует с вашими классами (логику) вы уже прописываете в контроллерах (Controllers).

Comments

[Nik Faraday]

Хорошо, но проблема в том, что я не знаю как разместить именно файлы View относительно друг друга. В шаблоне они просто друг на друге висят (Как в бесплатных htlm шаблонах, к примеру). А по логике паттерна их нужно как-то размещать по папкам относительно логики.
Так вот, как должна работать эта логика?

В конце концов, по стандарту создаётся контроллер Home и, соответственно, папка View/Home с некими стартовыми файлы. Как бы система сама намекает, что все View нужно разбивать по папка относительно контроллеров (Если имели дело, думаю, понимаете о чём речь).

А как дальше разбивать эту логику? Для примера, все файлы с navbar'а кинуть в отдельную папку. Или как-то страницы с доставки (Чисто для примера) в отдельную папку

Т.е., я реально пока что не могу понять сума структуру и как её нужно правильно строить, наговнокодить могу без проблем))

Спасибо)

[V Sh.]

Nik Faraday, можно все вспомогательные вещи (тулбары, меню навигации и пр.) хранить в отдельном контроллере, а во всех остальных вьюшках просто вызывать построение частичного представления с передачей параметров (PartialView). Ну и соответственно все cshtml у тебя будут храниться где-то в {HelperControllerName}/Navbar.cshtml.
Лично мне хватает функционала мастер-страницы и представления: все, что должно повторяться на каждой странице, я строю на мастер-странице, а в представлении контроллера строю только что-то специфичное.

[Nik Faraday]

V Sh., Попробую, спасибо

Answer 2

[Василий Банников]

Какого-то единого подхода нет, так что расскажу, как делаю я (но не в MVC проектах)

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

В aspnet проекте иерархию уже выстраиваю от путей запросов.
Тоесть если у меня будет эндпоинт GET /api/v1/orders, то и лежать он будет в папке api/v1/

В MVC будет аналогично, только добавятся ещё razor файлы и css
css лучше держать рядом с шаблонами, в которых они используются

Comments

[Nik Faraday]

CSS/Bootstrap/JS файлы выносятся в wwwroot и оттуда подключаются
Прочитайте ещё, пожалуйста, мой комментарий под ответом выше, я там более подробно описал вопрос
Спасибо

[Василий Банников]

Nik Faraday,

CSS/Bootstrap/JS файлы выносятся в wwwroot

Не пишу на MVC, так что тут да, не прав.

Вообще MVC сейчас считается достаточно устаревшим, и фронтенд следует делать отдельно от бэкенда.

[Nik Faraday]

Василий Банников, какие архитектурный паттерны используете вы?

[Василий Банников]

Nik Faraday, под MVC я имел в виду ASP NET MVC, когда бы формируем html на бэкенде.
Я предпочитаю делать отдельно фронтенд на каком-нибудь реакте (SPA), а бэкенд - чисто Rest API.
Если нужен прям статический фронтенд, то, думаю, вполне можно использовать next или nuxt для этого.

Лучше иметь возможность релизить бэк отдельно от фронта и наоборот, чем не иметь такой возможности.

Чисто архитектурно это похоже на MVC, только на месте View - JSON-ы

[Nik Faraday]

Василий Банников, я когда-то имел дело с чистым фронтом, и не больше зашла тема делать фронт при помощи бэк-тулов, и я в этом вижу много плюсов лично для себя
Я могу генерить сколько угодно элементов управления
Выводить списки товаров напрямую из БД
Да и в целом, использовать некий шаблон для элемента 100500 раз, чем писать это всё вручную и кидать URL на каждую )
(Сугубо моё мнение, если ваше мнение отличается от моего это нормально :D )

[Василий Банников]

Nik Faraday, наверно у меня такое мнение от того, что часто приходится делать один API и для фронта, и для мобилки, и для каких-то других сервисов, и ещё всё покрывать тестами.
При написании фронта отдельно, тестировать сильно легче, и кода меньше писать приходится.