Помогает ли Asp.net MVC создавать n-уровневые решения?

Question

Мое мнение таково: , а нет.

1. Он отделяет логику и данные от пользовательского интерфейса, но все же объединяет все это в одно приложение.
2. Вот почему я думаю, что это не совсем так, потому что контроллеры - это бизнес-логика, представления - это пользовательский интерфейс, модели - это DAL. Теперь это просто слои в одном приложении.

Но должны ли слои быть первым или вторым сортом, который на самом деле называется layer ?

Кто-нибудь хочет добавить свои 2 цента?

Answer 1

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

Answer 2

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

Answer 3

Конечно, это так!

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

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

Вы должны знать, что есть разница между логическим и физическим уровнями (или слоями и уровнями) ...

На сайте lhotka много интересных статей на эту тему!
Например. это и это .

Answer 4

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

Answer 5

«Уровень» обычно относится к разным физическим серверам, а «уровни» относятся к разделению функциональности на слабо связанные области.

То есть 3-уровневое веб-приложение: Уровень 1) БД Сервер Уровень 2) Веб-сервер Уровень 3) Клиентский браузер

3-х слойное веб-приложение: Слой 1) Пользовательский интерфейс Уровень 2) Бизнес-логика Уровень 3) Доступ к данным

Answer 6

Слои и ярусы являются взаимозаменяемыми. В контексте n-уровня вы бы назвали его уровнем представления, а в контексте многоуровневого приложения вы бы назвали его уровнем представления. Но на самом деле это одно и то же.

Лакмусовая проверка n-уровневого приложения и слабой связи была бы возможна, если бы вы могли взять каждый из уровней и построить их как отдельные проекты и развернуть их на разных машинах.

Ключевым отличием для n-уровневых приложений является разделение проблем (SoC) и слабая связь. Действительно отделенным приложением может быть приложение, в котором есть уровень, который содержит только чистый HTML. Затем другой, который содержит чистый Javascript и использует AJAX для обновления DOM и связи с веб-сервисом. Веб-сервис содержит собственный набор уровней.

Веб-сервис имеет механизм маршрутизации, который направляет запросы на разные контроллеры. Контроллеры дезинфицируют и интерпретируют запрос, проверяют аутентификацию, а что нет и вызывают соответствующие модели. модели, в свою очередь, должны возвращать объекты POCO или DTO и возвращать их в Javascript, который внедряет их в DOM. Javascript может изменять объекты и отправлять их обратно в базу данных. Entity Framework 4.0 имеет хорошую поддержку именно для таких n-уровневых сценариев , хотя в отделе SoC она немного отстает (например, строго типизирует представления), но практична для других целей.

MVC Futures Я полагаю, что имеется поддержка некоторых контейнеров Inversion of Control (IoC) из коробки, и в настоящее время, если вам нужна слабая связь и действительно n-уровневые сценарии, вам, вероятно, потребуется использовать контейнер IoC по вашему выбору.