Классы NHibernate как контракты данных

Question

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

Answer 1

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

Краткий ответ: Вы "должны" перевести свои классы NHibernate в модель предметной области.

Длинный ответ: Я думаю, что ответ на этот вопрос принципиален. Если вы когда-либо хотите взаимодействовать, вы должны не использовать наборы данных в качестве своих DTO ( Мне нравится пост Хансельмана на этом ). Я не говорю, что это никогда не хорошая идея; очевидно, что люди добились успеха в этом. Просто знайте, что вы режете углы, и это рискованное предложение.

Если у вас есть полный контроль над классами, в которые вы помещаете данные, вы можете построить хорошую модель предметной области и просто отобразить данные NHibernate в эти классы. Это, скорее всего, приведет к серьезным проблемам, поскольку IList <> (с которым сопоставляется ) не сериализуем. Вам придется написать свой собственный сериализатор или использовать что-то вроде NetDataContractSerializer , но вы потеряете совместимость.

Вам нужно будет измерить объем работы, связанной с созданием некоторых классов-оболочек, и их перевод, но тогда у вас будет полная гибкость в том, как будет выглядеть ваша модель предметной области. Затем вы можете делать такие вещи (как мы это сделали), такие как генерация кода для ваших карт и объектов NHibernate. Затем ваши контракты с данными служат абстракцией от ваших данных, как и должны.

P.S. Возможно, вы захотите взглянуть на ADO.NET Data Services , который является RESTful способом раскрытия ваших данных, который на данный момент представляется наиболее совместимым выбором для раскрытия ваших данных.

Answer 2

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

Answer 3

У меня нет прямого опыта в этом, но я отправлял наборы данных через WCF раньше, и это прекрасно работает. Я думаю, что вашей самой большой проблемой при использовании NHibernete в качестве объектов данных поверх WCF будет отсутствие взаимодействия (как и в случае использования наборов данных). Клиент должен не только использовать .NET, он также должен использовать NHibernate. Это идет вразрез с принципами SOA, но если вы точно знаете , что вы не будете использовать этот компонент повторно, то нет веских причин не делать этого.

По крайней мере, стоит попробовать.