Предположим, у меня есть класс с именем «Клиент», и имеет смысл иметь в классе такой метод, как:
void AddOrder(Item item, int quantity, decimal pricePerUnit)
Метод AddOrder концептуально создает новые записи в базе данных.
С точки зрения C # проблем с подписью метода выше нет, но для целей NHibernate он должен иметь доступ к ISession для сохранения новых объектов в базе данных.
Каков подходящий шаблон для достижения этого, не заставляя каждый метод в моих постоянных классах иметь параметр ISession?
Должен ли я унаследовать свои постоянные классы от общего абстрактного предка, который получает текущий экземпляр ISession с помощью внедрения зависимостей? (т.е. реализовать тонкую оболочку для ISession, которая действует как фабрика объектов, которая обрабатывает все запросы на создание или выборку)
Есть ли для этого хороший образец?
PS - Я знаю, что не хочу использовать шаблон репозитория. Это слишком произвольная форма для очень сложной модели данных.
Уточнение:
Рассматриваемая модель данных представляет собой систему бухгалтерского учета с двойной записью. Большинство разработчиков ничего не знают о механике двойного входа и не хотят этого. Итак, что я хотел бы сделать, так это предоставить методы кода, которые указывают разработчику «Что я могу сделать с этим объектом?», а не использовать только свойства, что является обычным способом NHibernate.
Я использовал NHibernate сейчас для изрядного количества проектов и постоянно возвращаюсь к выводу, что мне действительно следует поместить все взаимодействия с данными для очень сложных систем за высокоструктурированный API и единственные люди, которые работают над серверной частью. этого API должны быть экспертами по модели данных / сохраняемости. Программисты, которые просто взаимодействуют с данными, просто знают, как использовать API. Это не тот вывод, который я действительно хочу сделать, поскольку это приведет к значительным накладным расходам на разработку в некоторые из наших систем. (Конечно, это путь к сервис-ориентированной архитектуре, и в наши дни он может быть «данностью» для крупных проектов)
