C#: передать BusinessObject конструктору BusinessLayer или его методам?

Мне поручено поддерживать приложение C# Winforms, которое использует BusinessObjects (не содержащее логики, только свойства) и BusinessLayer с классами ("Helpers"), которые манипулируют этими объектами.

Вопрос: следует ли передать BusinessObject в конструктор Helpers, а затем внутри конструктора создать экземпляр общедоступной переменной Entity Helper ИЛИ следует ли просто передать Entity методам, которые с ним воздействуют?

Сценарий 1: К конструктору

Car myCar = new Car();
CarHelper ch = new CarHelper(myCar);
ch.Wash(suds);
ch.Upgrade(upgradeKit);
ch.Save();

Сценарий 2: К методам, которые воздействуют на Сущность

Car myCar = new Car();
CarHelper ch = new CarHelper();
ch.Wash(myCar, suds);
ch.Upgrade(myCar, upgradeKit);
ch.Save(myCar);

Две основные проблемы, которые у меня есть со Сценарием 1: A) Следующий разработчик должен копаться в классе CarHelper, чтобы понять, что у него есть общедоступное свойство доступа Car, на которое он ссылается в методах, которые в нем нуждаются. Это еще больше запутывает класс Helper в том смысле, что каждый метод должен проверять «нулевое» свойство Car перед выполнением своих обязанностей... B) Если между операциями существует куча другого кода, может стать неясным, что ch.Wash( ) на самом деле делает... действует ли он вообще на объект Car...?

Что все думают???


business-objects business-logic-layer
person Hellspawn    schedule 24.05.2011    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Есть ли причина, по которой вы не можете переместить логику в BusinessObject?

Car myCar = new Car();
myCar.Wash(suds);
myCar.Upgrade(upgradeKit);
myCar.Save();

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

вдвое меньше классов, которые нужно поддерживать

person Trent    schedule 27.05.2011

arrow_upward
0
arrow_downward

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

В «приложении» BusinessObjects находятся в пространстве имен (....ApplicationServices), на которое ссылается DAO, и поэтому он не может фактически вызывать методы DAO (поскольку это вызовет циклическую зависимость), поэтому он не может реализовать функциональность для

myCar.Wash(suds)
{
    this.CleanlinessRating = suds.CleaningAbilityRating;    
    // persist the level of Cleanliness to the DB
    CarDAO.Save(this);
}

Кажется, что предпосылка всего приложения заключается в том, что BusinessObjects вообще не реализуют никакой логики... они просто контейнеры информации и не имеют никакого поведения.

Затем у вас есть классы BusinessLayer, которые действуют на сущности...

Затем у вас есть классы DataLayer, которые сохраняют изменения в объектах в БД.

Таким образом, очевидно, заставить Сущности осознавать себя и реализовывать свое собственное поведение - это большое «нет-нет» (в этом приложении) ... я уверен, что это настоящая проблема здесь.

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

  1. Передать сущность методам, которые воздействуют на нее? ИЛИ ЖЕ
  2. Обернуть сущность в конструктор класса Helper?
person Hellspawn    schedule 27.05.2011

arrow_upward
0
arrow_downward

Как насчет того, чтобы ваш класс CarHelper расширял Car

CarHelper helper = new Car();
helper.Wash(suds);
helper.Upgrade(upgradeKit);
helper.Save();

Лучшее из обоих миров

person tgardner    schedule 27.05.2011