Как и в большинстве областей машиностроения, никогда не бывает идеального универсального решения для разработки или архитектуры. Так же и с n-уровневыми архитектурами.
Например, довольно много приложений отлично работают как одноуровневая или двухуровневая архитектура. Например, Microsoft Word работает достаточно хорошо, как одноуровневая система.
Большинство бизнес-приложений начали использовать слоев (в отличие от уровней: слои являются виртуальными, уровни - физическими), так как значительно упрощает жизнь, когда логика представления в одном месте, бизнес-логика в другом логика постоянства где-то еще. В зависимости от приложения может иметь смысл иметь гораздо больше слоев: я недавно закончил проект с шестнадцатью слоями между клиентом пользовательского интерфейса и базой данных SQL. (У нас были службы REST, уровни координации, смешанные базы данных, вы называете это. Создано для довольно сложной задачи развертывания.)
Приятная вещь во всех этих слоях:
- тестирование становится довольно простым, поскольку каждый слой выполняет одну-единственную вещь
- его можно масштабировать, особенно если вы создаете слои без состояния: тогда вы можете легко сгруппировать их и развернуть в отдельные блоки
- возможно, чтобы одновременно работало много разработчиков, если вы продолжаете общаться друг с другом
- изменения (обычно) ограничены одним слоем в коде
LINQ, Language Integrated Query, тоже очень помогает, поскольку может абстрагироваться от многих более сложных частей работы со слоями персистентности. Например
- SQL-подобный синтаксис довольно точно отображается в таблицы или представления базы данных SQL
- Работа с более сложными нереляционными данными, такими как XML-файлы, упрощена
Без LINQ разработка персистентных слоев была неизменно повторяющейся, и никогда не приносила пользы.