Должны ли когда-либо компоненты пользовательского интерфейса передаваться в сборку Business Logic для привязки

Question

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

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

Мой естественный подход - всегда отображать информациюэто требуется до пользовательского интерфейса и связать там.

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

Кто-нибудь когда-либо сталкивался?этот тип архитектуры раньше?Если да, то можете ли вы объяснить преимущества?

Решением является веб-сайт ASP.Net.Спасибо.

Спасибо,

Answer 1

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

Если это вообще возможно, вам следует подумать об удаленииот разработки сайта таким образом.Тем временем вы можете, по крайней мере, начать процесс развязки, разделив логику немного дальше.Если, скажем, у вас есть метод BindDropDown(DropDownList ddl), разделите метод на части, чтобы у вас был метод GetDropDownData(), который возвращает ваш фактический бизнес-объект, и BindDropDown only устанавливает значения DropDownList.Таким образом, по крайней мере, в будущем вам будет легче отойти от тесной связи уровня представления и уровня бизнеса.

Конечно, если сайт уже спроектирован таким образом (счеткое разграничение между уровнем представления, промежуточным уровнем «привязки представления» и бизнес-уровнем), я мог видеть случай, который является приемлемым.Однако не похоже, что это так.

Answer 2

Нет, вы должны не передавать элементы пользовательского интерфейса в модель предметной области для привязки / заполнения.

В идеале модель вашего домена должна использоваться с Windows Forms / WPF / Silverlight / ASP.NET / MVC, которую вы называете.

Теперь я немного понимаю идею, что ваши бизнес-объекты должны знать, как хранить и визуализировать себя и т. Д. Это священный грааль ОО, но на практике это не работает, поскольку часто существуют зависимости (промежуточное ПО базы данных, компоненты пользовательского интерфейса и т. д.) с теми функциями, которые вам не нужны в вашей сборке BO, это сильно ограничивает вашу возможность повторного использования.

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

public static class AddressUIExtensions
{
  public static void DisplayAddress(this Address add, AddressControl control)
  {
     ...
  }
}

Тогда пользователь API может просто сделать

var ctrl = new AddressControl();
address.DisplayAddress(ctrl);

но у вас все еще есть физическое разделение.

Answer 3

Ваш бизнес-уровень должен возвращать модель - модель представления, которую в свою очередь будет использовать уровень пользовательского интерфейса, чтобы заполнить то, что ему нужно - период.Не должно быть ничего отправлено на бизнес-уровень с точки зрения компонентов пользовательского интерфейса - точка.Это так просто и так сложно и быстро.

Answer 4

Кто-нибудь когда-нибудь сталкивался с подобным типом архитектуры?Если да, то можете ли вы объяснить преимущества?

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

Реализация правильной абстракции обычно требует времени и сложности.В большинстве случаев это именно то, что вам действительно нужно, но иногда приложение может быть создано как простой PoC.

В таких случаях не так много, что комната, заполненная людьми, садится и обсуждает архитектуру в течение нескольких часов и приходит к решению, что связывание в BL имеет смысл - обычно это "что угодно -вызов «сделай сам» - быстрый ответ разработчиков на скорость.

Конечно, эта простая лень или невежество, вероятно, послужит причиной его использования в других случаях.