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

Question

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

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

Мы строим систему HRIS с бизнес-аналитикой.

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

Answer 1

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

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

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

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

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

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

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

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

Успехов!

Answer 2

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

Answer 3

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

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

• Data Access Layer
• Business Logic Layer
• Presentation Layer

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

• Модель (уровень доступа к данным) (если вы используете Repository шаблон)
• View (Presentation Layer)
• Controller (Business Logic Layer)

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

Это не имеет никакого смысла.

Answer 4

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

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

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