Менеджер Классы?

Question

Я пишу приложение .net webforms. У него есть несколько классов, например, пользователи, бронирования и т. Д. На данный момент у меня есть несколько классов менеджеров, скажем, bookingManager, которые управляют этими классами. Например, при создании нового бронирования вы вызываете метод add в bookingManager и передаете бронирование. Затем он проверяет правильность бронирования, проверяет, не конфликтует ли он, и, если это не так, добавляет его в БД. У меня есть похожие менеджеры для других классов, однако такие, как менеджер пользователя, не делают больше, чем принимают пользователя и добавляют в БД. Поэтому мой вопрос заключается в том, является ли это наилучшим способом делать подобные вещи, или есть шаблон или метод, который лучше подходит для этого?

Answer 1

Если менеджер похож на контроллер / презентатор между пользовательским интерфейсом и классами доменов, я думаю, что это должен быть тонкий слой. Он должен содержать несколько строк кода. Тогда доменные службы или сервисные классы должны позаботиться об отдыхе. Например:

UI:

buttonClicked(Eventargs...)
{
   presenter.Save();
}

Presneter:

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
}

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

Answer 2

как вы описываете, вы уже используете паттерн, 3-х уровневый паттерн :)

Это означает, что в приложении ваш код должен быть разделен на 3 уровня (как следует из названия):

1. Уровень представления: где вы пишете код для представления ваших данных (ASPx / winforms / etc)

2. Уровень приложения: куда вы помещаете всю свою бизнес-логику (что вы делаете с классами менеджера)

3. Уровень данных: где вы делаете фактический доступ к базе данных.

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

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

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

http://en.wikipedia.org/wiki/Multitier_architecture

Answer 3

Я думаю, что всегда лучше реализовать метод Save, Delete и Update для таких классов. Класс менеджера для таких вещей, безусловно, излишним. Те методы, которые реализованы в вашем, скажем, классе бронирования, могут выполнить ту же проверку и избежать любых сложностей, связанных с добавлением слишком большого количества классов в ваш код.

Answer 4

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

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

2. «Менее приятная» вещь в менеджерах состоит в том, что у вас есть другой компонент, который, вероятно, будет достаточно тесно связан с другими компонентами в системе. Вам необходимо сбалансировать плюсы и минусы этого и выбрать архитектуру, наиболее подходящую для вашего приложения.