C #: передать BusinessObject конструктору BusinessLayer или его методам? - PullRequest
Новая
       38

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

0 голосов
/ 24 мая 2011

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

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

Сценарий 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: А) Следующий разработчик должен изучить класс CarHelper, чтобы понять, что у него есть общедоступное свойство доступа к Car, на которое он ссылается в нужных ему методах. Это еще больше запутывает класс Helper тем, что каждый метод должен проверять наличие «нулевого» свойства Car перед выполнением своих обязанностей ... Б) Если между операциями существует куча другого кода, может стать неясно, что на самом деле делает ch.Wash () ... Он вообще действует на объект Car ...?

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

Ответы [ 3 ]

0 голосов
/ 27 мая 2011

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

In 'приложение '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, которые сохраняют изменения в объектах БД.

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

Howevэ-э, если я не могу это изменить, что бы вы сделали?

  1. Передать сущность методам, которые на нее воздействуют?ИЛИ
  2. Обернуть сущность в конструктор класса Helper?
0 голосов
/ 27 мая 2011

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

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

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

0 голосов
/ 27 мая 2011

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

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

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

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

...