Как решить, какой из них следует использовать в веб-приложении MVC или трехуровневой архитектуре?

Question

Если нам нужно будет выбрать какой-либо один шаблон архитектуры для веб-приложения в .Net, какой из них будет лучшим, MVC или трехуровневый, как решить?

Answer 1

Jeevan,

Я думаю, что вы, к сожалению, следите за ходом размышлений, которые многие разработчики, не знакомые с MVC, принимают, поскольку вас «кормят» убеждением, что «M» в mvc (модель)это просто плоская реализация linq2sql и это все для модели.Не так ... в наших приложениях мы должны обслуживать различные веб / настольные и портативные устройства, используя различные области их общих функций.поэтому мы создали dll «BLL / DAL» со всей нашей бизнес-логикой, которая упоминается как «M» в наших приложениях mvc.Этот же «bll / dal» используется в наших приложениях веб-форм, а также в наших настольных приложениях.в одном текущем приложении мы подключаемся к серверному оракулу с помощью нашего bll / dal dll и используем MVC исключительно в качестве службы RESTful, выступающей в качестве посредника между двумя устаревшими системами.учитывая дизайн нашего bll / dal dll, мы могли бы так же легко переключить его на sqlserver, если (как и когда) бизнес потребует.

, так в двух словах, предложение о выборе MVC или 3-го уровня (и я на самом деле думаю, что вы имеете в виду многоуровневый, а не многоуровневый [что больше относится к физическому разделению функций / сервисов]) - это спорный вопрос, поскольку они сходятся, а не разрозненные технологии.Я попытаюсь привести некоторые примеры через mr google позже сегодня, чтобы проиллюстрировать полноту моего подхода.

[edit] - из аналогичного вопроса здесь на SO; N-уровень относится только к физической структуре реализации.Эти два иногда путаются, потому что проект MVC часто реализуется с использованием N-уровневой архитектуры.

MVC против n-уровневой архитектуры

в двух словах , один - это объект / API, другой - системная архитектура;оба могут жить счастливо вместе.

Answer 2

Оба понятия довольно высокого уровня, и со всеми понятиями высокого уровня нет однозначного ответа. Более того, вы можете довольно успешно смешивать их. Например, используйте многоуровневое приложение на уровне представления, если ваше приложение достаточно велико, чтобы это требовалось (например, у вас был большой кластер данных + уровень аналитики + уровень отчетности).

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

1. В какой архитектуре вы и ваша команда чувствуете себя наиболее комфортно, чтобы уложиться в срок
2. Насколько сложным на самом деле является ваше приложение и какие преимущества получит использование одной из этих архитектур
3. Какую модель использования будет использовать ваша система, и какое архитектурное решение лучше соответствует потребностям этих моделей использования
4. Насколько ремонтопригодным будет каждое решение

Этот список можно продолжать, конечно, но я думаю, что эти 4 вещи помогут вам встать на правильный путь.

Исходя из моего опыта, архитектура более или менее сложной, реальной системы жизни (которая не является академической фантазией) никогда не бывает MVC или трехуровневой, но всегда представляет собой смесь многих вещей:)