Лучший подход для создания NHibernate DTO
Синтаксис языка, варьируются подобные, таким образом, я должен только считать маленькую ссылку синтаксиса C#. Как простая книга (для опытных программистов) или возможно Википедия ( http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp ) скажет достаточно.
самым большим различием является библиотека: Asp. Сетевые веб-сайты полностью отличаются от сервлетов Java.
не читают очень, только начинают программировать!
4 ответа
В общем, DTO не содержат поведения (например, «Сохранить», «Загрузить») и не содержат информации о том, как они сохраняются (ISession). Похоже, что вы действительно создаете слой данных. В идеале ваш бизнес-уровень также не должен знать об ISession. Тем не менее, вы можете сокращать это многоуровневое размещение как хотите, так как оно соответствует вашим потребностям, но, вероятно, будет трудно изменить ORM позже, если ваша ORM просочится через все ваши уровни.
Для управления временем жизни ISession вам необходимо решите, собираетесь ли вы использовать шаблон UnitOfWork, который в основном говорит, что каждый пользовательский запрос получает новый ISession. Существуют и другие варианты времени жизни ISession, и вы действительно не ограничены в этом отношении. Часто могут быть лучшие практики в отношении веб-приложений, приложений для Windows и любых других типов приложений,
Храните код загрузки / сохранения отдельно от DTO. Объекты DTO - это только представления базовых данных.
При выполнении запросов возвращайте DTO с помощью преобразования. Примерно так:
resultSet = session.CreateCriteria(typeof(MyDataObject))
.Add(query criteria, etc.)
.SetResultTransformer(Transformers.AliasToBean<MyDTOObject>())
.List<IMyDTOObject>()DTO должны быть «объектами передачи данных». То есть немые объекты, используемые для передачи значений или коллекций значений в вашей системе. Они не должны нести ответственность за сохранение самих себя или даже за сопоставление 1-1 с объектами домена на уровне вашего домена.
Открытие / закрытие ISession очень недорогое. Проблема с тем, чтобы держать его открытым слишком долго, заключается в том, что пул соединений не может повторно использовать соединение, пока не истечет время ожидания или что-то еще. Это может быть проблемой в многопользовательском приложении.
В вашем сценарии я бы, вероятно, выбрал сервис-ориентированный подход для хранения извлекаемых данных. это означает, что DTO будет использоваться только внутри границ службы. Если вам нужно скопировать объекты, которые выглядят одинаково, я предлагаю вам взглянуть на AutoMapper , который был создан для этой конкретной цели. Если у вас есть проект только для Windows или только для Интернета, это не проблема. Это когда вы смешиваете. Вы не можете обрабатывать сеансы в приложении для Windows так же, как в веб-приложении.