Режим MVC: Model View намагається керувати контролером, який є поточним основним режимом і використовується як базовий спосіб входу серверного програмного забезпечення для навчання та освоєння, а основний фреймворк Struts 1/2 JSF Wicket фактично підтримує режим MVC.
Однак із постійною популяризацією B/S та Інтернет-застосунків, Web 2.0 та великої кількості частих інтерактивних додатків, таких як соціальні мережі та ігри, відносно статичний режим MVC більше не підходить для дуже інтерактивних і поведінково орієнтованих додатків.
Саме моделювання домену DDD приділяє більше уваги структурі, його значення сутності об'єкт і сервер також є своєрідним структурним поділом, але воно не підкреслює важливість обов'язків і поведінки об'єктів, і це єдина різниця між об'єктами та базами даних.
Навпаки,Дизайн об'єктів: ролі, обов'язки та співпрацяУ книзі пропонується, що об'єкт фактично виконує певну роль, і роль є відповідальною, а потім певна інтерактивна поведінка буде реалізована в певному контексті сцени, що було повністю обговорено в Jdon:
DCI, доменна модель, кілька ідей для доменних подій
Асинхронне архітектурне мислення: Реалізувати моделювання доменів за допомогою Akka
Книга підсумовує чотири основні недоліки централізованих контролерів, і контролери MVC фактично належать до цього централізованого стилю контролерів:
1. Логіка керування може бути надто складною. Контролери можуть бути складними, і багато людей часто пишуть бізнес-код у контролерах Action від Struts.Усі дії — це дії, а деякі — це майже тисячі рядків.
2. Контролери можуть залежати від вмісту власників інформації. Контролери стають залежними від інформаційних дата-центрів або баз даних, контролери виконують багато речей, тобто доменні об'єкти роблять дуже мало, і контролер не лише робитиме що врешті-решт, а й вирішує стратегічні рішення, а також тактичні питання, такі як як це робити і як реалізувати.
3. Об'єкти можуть зв'язуватися опосередковано через дії свого контролера. Об'єкти опосередковано пов'язані між собою через дії контролера, один об'єкт запитується в контролері, потім копіюється в інший об'єкт, і обидва об'єкти зв'язуються між собою.
4. Єдина цікава робота виконується в контролері.
Контролер MVC — це свого роду режим медіатора, але також централізований контролер; це головна відмінність від режиму спостерігача: режим медіатора інкапсулює комунікацію, тоді як режим спостерігача — децентралізований зв'язок, з точки зору комунікації, контролер також має свої вроджені недоліки: легко стати великим і повністю з'єднаним концентратором, усе це призначено дляООЦе не терпимо.
Архітектура DCIЦе нова концепція, яка з'явилася лише нещодавно і дивиться на програмне забезпечення з нової перспективи, що збігається з і є правим щодо дизайну, орієнтованого на обов'язкиDDDрозвиток і вдосконалення.
DCI — це скорочення від Data Context Interactions, і його важливий внесок полягає в просуванні концепції сцен, яка не згадується в книзі Duty-Driven Development, яка лише заперечує MVC, виявляє його проблеми і не пропонує альтернативDCIЦе альтернативна архітектура MVC, і DCI замінює MVC сценаріями для заміни контролерів, як показано на рисунку нижче (на фото).Оригінальна англійська TheDCI Architecture: A New Vision of Object-Oriented Programming)：
Сцена фактично витягує деякі елементи керування та моделі з MVC і збирає їх у вигляді сцен із персонажами. Це новий кут, який повністю відрізняється від розгляду режиму MVC, що більше відповідає цьому кутуОО。
Нещодавно хтось підняв це питанняКонтекст сцени — це новий тип об'єкта, сцену можна не лише замінитиSOAВеб-сервіси також можуть замінити контролери MVC.
Особисто я вважаю, що нова ієрархічна архітектура в майбутньому може виглядати так:
Переглянути --> Контекст ---> доменну модель ---> компонента/репозиторію
Режим MVC мертвий.
|
Опубліковано 06.12.2014 22:17:21
|
|
|
|
Опубліковано 07.12.2014 17:23:04
