Чому всі ставлять контролери в одну папку і переглядають в іншу?

Я готуюсь витягнути згин з asp та в рамки mvc, asp.net mvc або nancy. Куди б я не поїхав, я бачу папки для контролерів / модулів та папки для переглядів. Це просто павловій рефлекс прибирання речей за типом, чи є якась більш глибока мудрість? У мене є невеликий проект, що підтверджує концепцію, де я зберігаю разом файли, які я, швидше за все, відкрию разом, суттєвий комфорт. Оскільки ці файли також можуть викликати один одного, вони можуть робити це за допомогою коротших, менш крихких, відносних посилань. Цю модель оскаржує mvc, оскільки шлях до папки більше не відповідає автоматично URL-адресі, а в asp.net mvc шаблони проектів і маршрутизація примушують переглядати \ контролери \ schism.

На цій сторінці мікрософт представлено поняття областей. Це може сприйматися як визнання того, наскільки грізні великі додатки стають через це штучне розділення.

Люди будуть заперечувати проти "поділу проблем", але розділення проблем вже досягається наявністю окремих вихідних файлів. Немає конкретного виграшу, як мені здається, від того, щоб взяти ці вихідні файли, щільно з'єднані, та відправити їх на протилежні кінці структури папки?

Хтось ще бореться з цим? Якісь поради?

Хотілося б сказати, що це програмування культового культу , але для цієї структури є технічні причини. Asp.Net MVC прийняв конвенцію щодо конфігураційного підходу майже до всього. За замовчуванням двигун подання Razor шукає Viewsкаталог, щоб вирішити, який вид повернути з контролера. Однак є кілька хаків, щоб отримати іншу структуру проекту, і Microsoft навіть надає функцію MVC під назвою « Області», щоб ми могли створити більш чітку структуру проекту. Ви також можете застосувати власну систему перегляду , щоб вказати, де шукати представлення даних.

Чому я можу сказати, що це вантажне культове програмування і що ви прав? Дядько Боб переконав мене, що структура каталогів проекту не повинна мені говорити, що це програма MVC. Це повинно сказати мені, що це фронт-магазин, або система запитів на вихід, або що завгодно. Структура та архітектура високого рівня повинні говорити про те, що це за річ, а не як вона була реалізована.

Коротше кажучи, я вважаю, що ви маєте рацію з цим, але будь-яка інша структура каталогів просто билася проти фреймворку і довіряйте мені, коли я кажу, що ви не хочете намагатися змусити рамку Asp.Net MVC зробити щось таке, чого не було не призначений для цього. Шкода, що це насправді не налаштовується.

Щоб швидко вирішити питання архітектури, я все-таки вважаю, що бізнес-моделі (бізнес, а не перегляд) та DAL повинні жити в окремому проекті / бібліотеці, що викликається з вашого додатку MVC.

Просто контролер дійсно дуже щільно поєднаний з видом і, ймовірно, буде змінений разом. Ми всі мудрі пам’ятати про різницю між сполученням через залежність та логічним зв’язком. Тільки тому, що у коду були свої роз'єднані залежності, це не робить його менш логічно сполученим.

Якою б не була причина, це погана практика. Це дуже анти-OO, тому що пакети або папки (як би ви їх хотіли називати), повинні мати слабкі взаємозалежності. Класи (або файли) всередині них повинні мати сильні взаємозалежності.

Перекидаючи всі перегляди в одну папку та всі контролери в іншу папку, ви створюєте два пакети з дуже дуже щільним з'єднанням. Це суперечить принципу слабкої міжпакетної залежності.

Вид і контролер - це дві половини цілого і повинні належати одна одній. У вас не було б одного розіграшу шафи для шкарпеток лівого боку, а іншого малюнка для шкарпеток правого боку.

Щоб відповісти на ваше "Чому всі ...?" питання: Ось кілька потенційних причин, хоча я не зовсім впевнений, яке їх поєднання є справжньою причиною, оскільки це насправді суб'єктивне питання

• Для копіювання логічної архітектури (модель, перегляд, контролер) із відповідною структурою папки та простору імен

• Позаконно та зручно слідувати шаблону проекту ASP.net MVC

• Групувати за простором імен, оскільки Controllers/папка призведе до .Controllersпростору імен

• Можна ввімкнути деякі сценарії в DI / IoC, коли класи контролерів запитуються / скануються лише з простору імен, що містить / закінчується "Контролерами" (це може бути неправильно)

• Щоб дозволити шаблонам T4 сканувати та моделювати ескізи та контролери для генерування представлень

Ви завжди можете створити та дотримуватися власної конвенції, якщо це має сенс для вашого проекту, ніхто не зможе / не зупинить вас. Але майте на увазі, що якщо ви працюєте у великому проекті та / або великій команді, то кращий вибір може бути стандартним умовою за замовчуванням, яке відоме всім (не обов'язково правильному!)

Якщо ваш конвент простіше дотримуватися і не перешкоджає продуктивності, то будь-якими способами робіть це! а може навіть написати про це повідомлення в блозі чи два, щоб поспілкуватися з спільнотою розробників та отримати зворотній зв'язок

Однією з причин збереження поглядів та контролерів в окремих каталогах є те, коли у вас є розробники переднього та заднього кінців, які працюють над проектом. Ви можете заборонити розробникам переднього кінця отримати доступ до коду зворотнього зв'язку (наприклад, для сприяння дотриманню PCI, обмеження доступу до чутливого коду).

Ще одна причина - полегшити створення «тем» та вимкнути всі шаблони, внести незначні зміни в шлях перегляду.

Третя причина полягає в тому, щоб мати простий шаблон каталогів, коли вказувати представлення в рамках MVC. Простіше вказати підкаталог та файл, а не великий довгий шлях до кожного перегляду.

Єдиною "щільною муфтою" має бути:

1. Змінні, що надсилаються у вигляд контролером.
2. Поля форми або дії у вікні перегляду відправляються назад до контролера.

Я використовую загальний контролер і намагаюся зберігати імена змінних у загальному вигляді перегляду, так що багато представлень можуть використовувати один і той же контролер, і багато контролерів можуть використовувати один і той же вигляд. З цієї причини я вважаю за краще тримати погляди повністю окремими. Модель - це те, де ви можете розмежувати кожну «річ» у вашій програмі - це можуть бути об’єкти зі списком властивостей та методів доступу / зміни цих властивостей.

Що стосується щільно зв'язаного коду, підхід, який може працювати для вас, полягає в тому, щоб всі файли, що входять до пакету або "модуля", зберігати разом у каталозі, розміщеному іменами. Тоді ви можете використовувати скрипт, щоб скопіювати або "скласти" ваші неочищені шаблони в основний каталог "перегляди". Наприклад:

    lib/my-namespace/my-package/
        -> controllers/
        -> models/
        -> views/
            -> theme/
               -> template-name1
    app/compiled_views/theme/
        -> url/path/template-name1

На жаль, якщо ви хочете змінити структуру існуючої теми, для оновлення представлень подань до каталогів пакунків існує більше вбудовування та виходу з каталогів пакетів.

Подумайте, що представлення даних - це лише спосіб форматування даних, будь то json, xml, csv або html. Це особливо допомагає, якщо ви хочете, щоб ваша програма також працювала як API. Спробуйте від'єднати представлення даних від даних, використовуючи загальні імена змінних, щоб ви могли використовувати один і той же шаблон для багатьох контролерів або моделей (або використання включає мінімізацію кількості коду, який потрібно підтримувати).

Не обов’язково всі так роблять. Наприклад, рамка Django python має концепцію програми, де підмодулі вашої програми живуть у власних каталогах із власними моделями та переглядами та шаблонами (перегляди - це те, що Django по суті називає контролерами). Мені здається, що я віддаю перевагу такому способу роботи, тому що це означає, що я можу легко упакувати "додаток" і повторно використовувати його в різних проектах, просто включивши його до списку програм у налаштуваннях моїх проектів. Так само простіше дізнатися, де знаходяться різні частини. Якщо я переглядаю файл urls.py і бачу щось подібне url(r'^users/', include('my_site.users.urls')), я знаю, що модуль my_site.usersмістить весь код, який обробляє користувачів. Я знаю, щоб подивитися на модулі, my_site.users.viewsі my_site.users.modelsколи я хочу побачити, як створюються та автентифікуються користувачі. Я знаю, що всі мої маршрути визначені в my_site.users.url.

Крім того, якщо він достатньо загальний, я, ймовірно, можу використовувати цей модуль на інших сайтах, просто змінивши конфігурацію або запакувавши його як бібліотеку та опублікувавши його як OSS.

Пам’ятайте, що це рекомендований Microsoft спосіб зберігати контролери та представлення даних у різних папках, тому багато хто дотримуватиметься рекомендованої структури,

1. Однією з причин може бути те, що контролери завжди не мають відносин один до одного з поглядами, особливо часткові погляди можуть ділитися між контролерами.
2. Інша причина може бути, коли ваш проект зростає, ви можете витягнути контролери та тестові одиниці до іншого проекту, але це досить важко зробити так само, щоб представлення, а перегляди / js / css належать разом, коли вони посилаються один на одного.

Сказавши, що існує багато дописів про те, як зробити це так, як це .

Для запису

Чому я можу сказати, що це вантажне культове програмування і що ви прав? Дядько Боб переконав мене, що структура каталогів проекту не повинна мені говорити, що це програма MVC. Це повинно сказати мені, що це фронт-магазин, або система запитів на вихід, або що завгодно. Структура та архітектура високого рівня повинні говорити про те, що це за річ, а не як вона була реалізована.

Питання: Хто має доступ до коду ?. Програмісти. Чи дбають кінцеві користувачі про код ?. Ні. І те, що робить програміст, код. Або, більш конкретно, класи на основі типів (контролери, сервіс, модель тощо). Тож має сенс і налагодити код легко, якщо ви зможете знайти код на основі типу коду, а не за поведінкою коду. Плюс, скажімо, командний проект, один відповідає за контролер, інший за моделлю, інший дао та інший з точки зору. Легко розділити проект на частини. Хороший код - це код, який легко налагодити, а не синтаксичний цукровий код. Дядько Боб знову помиляється.

Спроба імітувати поведінку проекту (передній магазин) - це культовий культ.