Классы менеджеров?
Я пишу приложение для веб-форм .net. У него есть несколько классов, например, пользователи, бронирования и т. д. На данный момент у меня есть несколько классов менеджеров, например, bookingManager, которые управляют этими классами. Например, при создании нового бронирования вы вызываете метод add в bookingManager и передаете бронирование. Затем он проверяет действительность бронирования, проверяет, не конфликтует ли оно, и, если это не так, добавляет его в базу данных. У меня есть аналогичные менеджеры для других классов, однако такие, как менеджер пользователей, не делают ничего больше, чем просто принимают пользователя и добавляют его в БД. Итак, мой вопрос: это лучший способ делать подобные вещи или есть шаблон или метод, который лучше подходит для этого?
Ответы 4
Нет ничего плохого в том, чтобы иметь классы менеджеров, особенно когда они управляют несколькими различными аспектами системы, такими как упомянутый вами менеджер по бронированию. В этом случае вы можете не захотеть, чтобы пользователь знал о бронировании или о бронировании знал о пользователях, но это, естественно, будет зависеть от специфики вашей системы.
В менеджерах хорошо то, что они обеспечивают центральное и логичное место для хранения, возможно, сложной логики, которая зависит от нескольких компонентов. Это также позволяет вам использовать классы данных как таковые и увеличивать сплоченность этих классов.
«Менее приятным» в менеджерах является то, что у вас есть еще один компонент, который, вероятно, будет достаточно тесно связан с другими компонентами системы. Вам нужно сбалансировать плюсы и минусы этого и выбрать архитектуру, наиболее подходящую для вашего приложения.
Я считаю, что для таких классов всегда лучше реализовать методы сохранения, удаления и обновления. Класс Manager для таких вещей определенно избыточен. Эти методы, реализованные, скажем, в вашем классе Booking, могут выполнять ту же проверку и избегать каких-либо сложностей, связанных с добавлением слишком большого количества классов в ваш код.
как вы это описываете, вы уже используете узор, трехуровневый узор :)
Это означает, что в приложении у вас должен быть свой код на 3 уровня (как указано в названии):
Уровень представления: где вы пишете код для представления ваших данных (ASPx / winforms / и т. д.)
Уровень приложения: где вы размещаете всю свою бизнес-логику (что вы делаете с классами менеджеров)
Уровень данных: где вы осуществляете фактический доступ к базе данных.
Следование этому шаблону может быть полезно, когда у вас есть что-то вроде клиента с несколькими адресами, который хранится в одной таблице, а адреса - в другой. На уровне представления вы просто вызываете метод на уровне приложения для сохранения клиента. На уровне приложения вы проверите свои данные и вызовете два метода на уровне данных, один для сохранения, другой для сохранения адресов.
Теперь, если у вас есть поставщики с несколькими адресами, вы можете использовать один и тот же метод на уровне данных для их сохранения.
Это будет полезно, если у вас есть сложные объекты. однако, если большинство ваших объектов просто просты, я бы порекомендовал вам подумать, подходит ли вам этот шаблон.
Если менеджер похож на контроллер / ведущий между пользовательским интерфейсом и классами домена, я думаю, что он должен быть тонким слоем. Он должен содержать несколько строк кода. Тогда об остальном должны позаботиться доменные службы или классы обслуживания. Например :
UI:
buttonClicked(Eventargs...)
{
presenter.Save();
}
Преснетер:
public void Save()
{
bookingService.Save(view.Name,view.DateTime...)
}
Услуга :
public void Save(string name,DateTime dateTime...)
{
//do operations or call repository/Dao classes to save
}
это может быть излишним для небольших приложений, но для больших приложений это увеличивает ремонтопригодность. Вы можете посмотреть книгу Domain Driven Design и классы доменных служб.