Я согласен с вами в том, что взаимодействие с бизнес-слоем должно быть максимально простым, со сложными типами и другой сложностью скрыто, или в чем смысл. В точке, где подключены объекты пользовательского интерфейса и бизнеса, должна быть как можно меньше сложности 0.
Я могу представить себе сценарии, где построение относительно сложных типов в этом пункте было бы законным. Чем меньше сайт, тем более вероятно, что < 3 уровня могут быть лучше, чем строгий 3 уровня. Поэтому, чтобы быть откровенным в отношении комплектов стартеров, которые вы видите: возможно, масштаб настолько мал, что строгое разделение проблем будет излишним, и их подход вполне может быть подходящим для ситуации. Или, что они делают, так это complex, что это лучший способ справиться с этим. Чем сложнее проводка или интеграция, или если есть подключаемая модель или что-то еще, то, казалось бы, слишком сложный тип может быть тем, что обеспечивает согласованный гибкий интерфейс. Иногда небольшая сложность в одном месте экономит вам массу сложности в другом месте. Но чаще это не так. Я предполагаю, что на самом деле то, что вы видите как плохое. , , плохой.
- Многие Microsoft быстро начала демки и шаблоны имеют очень плохую архитектуру. Модель веб-форм сама по себе не поддается хорошему Разделение проблем. Вы увидите много официальных примеров: spaghetti code кошмары. Бизнес, DB и пользовательский интерфейс живущих вместе - это ужасная гармония.
- Если вы говорите о 3-й партии SDKs: многие из них требуют сложных типов, передаваемых в бизнес-объекты , потому что они были перенесены из C++ , но никогда не пересмотренные быть объектно-ориентированным. Пару раз мне приходилось делать какие-то безумные типы, чтобы перейти к некоторым объектам программного обеспечения для обработки изображений, где логически потребовалось только два простых значения параметров.