Преобразование ASP.NET MVC в многоуровневую архитектуру

Question

Я только что создал приложение, используя ASP.NET MVC. Программисты в моей компании хотят построить все будущие модули, используя архитектуру n-Tiered (уровень представления, уровень бизнес-логики, уровень доступа к данным).

Я не программист, и мне нужно знать, почему это имеет смысл? Нужно ли полностью переписывать весь код или его можно конвертировать?

Мы создаем систему HRIS с помощью Business Intelligence.

Кто-нибудь, пожалуйста, объясните, почему или почему этот подход не имеет или не имеет смысла.

Answer 1

Честно говоря, это не имеет смысла для меня.

В архитектуре "N-Tier" у вас есть три уровня:

• Уровень доступа к данным
• Уровень бизнес-логики
• Уровень представления

В MVC (сокращение от M odel, V iew, C контроллер), у вас есть три слоя:

• Модель (Уровень доступа к данным) (если вы используете шаблон Репозиторий)
• Просмотр (Уровень представления)
• Контроллер (Уровень бизнес-логики)

Короче говоря, ваша заявка уже написана, и обеспечивают разделение интересов. Теперь они хотят переписать его, чтобы просто переименовать папки?

Это вообще не имеет смысла.

Answer 2

Уровни больше связаны с физической архитектурой, чем с логической?см. Многоуровневая архитектура

Если вы отделили M, V и C друг от друга в своем текущем приложении, у вас уже есть хорошая логическая архитектура.

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

Answer 3

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

Трехуровневые архитектуры - хорошая идея, поскольку они, как правило, легко разделяют проблемы классов, превращая их в более гибкие и понятные категории:

1) данные / постоянство 2) бизнес-логика 3) представление / GUI

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

Теперь возможность достижения трехуровневой архитектуры путем рефакторинга существующей базы кода в значительной степени зависит от того, как этот код был разработан. И это поднимает давний вопрос разработки программного обеспечения: мы проводим рефакторинг или начинаем с нуля? Все зависит от кода ... и людей, пишущих "новый" код.

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

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

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

Удачи!

Answer 4

Трехуровневый подход действительно способствует лучшему повторному использованию в будущем. Фактически, ваше недавно построенное приложение на основе MVC может использовать трехуровневую модель (по крайней мере, модель и части контроллера). Контроллер MVC может выступать в качестве фасада с использованием 3-уровневого решения в фоновом режиме.