Должна ли организация когда-либо знать что-либо о своем DAO? - PullRequest
Новая
       31

Должна ли организация когда-либо знать что-либо о своем DAO?

4 голосов
/ 24 августа 2010

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

В моем вымышленном примере, скажем, у меня есть CarDAO и сущность Car: 

public interface CarDAO {
    Car FindById(int id)
    ... // everything else
}

public interface Car {
    ... various properties and methods
}

У меня должна быть возможность перевести автомобиль на правостороннее управление. Поскольку это будет очень сложная операция, мне нужно выполнить хранимую процедуру. Мне неясно, куда должен идти метод ConvertToRightHandDrive ().

Для меня имеет смысл поместить метод в Car и позволить ему вызывать метод в CarDAO, который будет выполнять хранимую процедуру. И вот тут мне непонятно:

  • должен ли Car иметь ссылку на CarDAO и вызывать CarDAO.ConvertToRightHandDrive?
  • должен ли быть какой-то слой CarService, который вызывает CarDAO.ConvertToRightHandDrive?
  • как насчет внедрения CarDAO с помощью метода на Car (Car.ConvertToRightHandDrive (carDAO))
  • какой-то другой вариант?

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

Ответы [ 2 ]

1 голос
/ 24 августа 2010

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

Если вам нужно вызвать хранимую процедуру для преобразования автомобиля в правостороннее управление, мне нравитсявозможность иметь метод CarDAO.ConvertToRightHandDrive(Car car), а затем использовать что-то вроде класса CarService, чтобы скрыть зависимость от CarDAO от любых вызывающих (т. е. класс CarService будет иметь идентичный метод, который просто перенаправит вызов на CarDAO).

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

1 голос
/ 24 августа 2010

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

Таким образом, в этом случае CarManager (или аналогичный), который, возможно, зависит от CarDAO, должен иметь метод ChangeToRightHandDrive(Car).

Да, и еще одно преимущество наличия CarManager, который выполняет сложные операции, заключается в том, что вы не полагаетесь на хранимые процессы. Это почти наверняка религиозная проблема, но я предпочитаю иметь всю логику в моем коде, а не полагаясь на SP (есть несколько исключений, но обычно только вокруг больших наборов). Это означает, что если вы перешли на другой DAL (скажем, XML), вам не нужно будет повторно реализовывать ваш SP в DAL/DAO - в противном случае вы получите бизнес-логику, встроенную в ваш DAL.

...