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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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