2010-07-29 2 views
3

Это то, что тянуло меня некоторое время. Рассмотрим веб-приложение (тип MVC) с ORM (например, Nhiberate) в качестве уровня доступа к данным.Nhibernate (и ORM в целом): работа с объектами или объектами?

С одной стороны - ООП/модель Rich домена руками - Я чувствую, что должно быть обход (ссылки) реальные объекты, я имею в виду.

С другой стороны - БД/Web App рука - Я чувствую, что это проще и эффективнее просто передать целочисленные Идентификаторы объектов, а не сами объектов.

Рассмотрим электронной коммерции типа каталога приложения:

  • пользователь вошел в систему и переходит к странице продукта.
  • Опубликовать комментарий.
  • Действие контроллера, которому необходимо сохранить этот комментарий, содержит 3 части информации: a) идентификатор пользователя (из файла cookie или где-либо), b) идентификатор продукта (возможно, из строки запроса) и c) текст комментария.
  • Теперь, какая здесь лучшая практика? Действительно ли стоит раздувать объекты пользователя и продукта (например, получая их из репозитория со всей работой БД, что влечет за собой), когда мы знаем, что все, что они будут использовать, так это то, что ORM может читать свои идентификаторы и устанавливать соответствующие внешние ключи в таблице БД, где хранятся комментарии?

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

Это общий вопрос, который, вероятно, применимо ко многим платформам, но , если приводить примеры, я бы предпочел, чтобы они были ASP.NET MVC, если это возможно.

спасибо.

+0

Как проще «просто» пройти вокруг идентификаторов, а не ссылки? Кроме того, помимо получения дополнительной сущности из базы данных, это более результативно? – apollodude217

+0

@Apollodude: конечно, как только вы * имеете * объекты, они не более эффективны - это не моя точка. Но два ненужных извлечения ББ заставляют меня вздрагивать. Проверьте решение Daniel Auger, которое удовлетворяет всех. – UpTheCreek

+0

Я согласен с тем, что проблема с производительностью вполне справедлива. Я хотел понять, какие еще преимущества вы получили. – apollodude217

ответ

3

NHibernate имеет нагрузку (в отличие от получения) именно по этой причине.

session.Save(
    new Comment 
     { 
     Text = commentTextFromScreen, 
     User = session.Load<User>(userID), 
     Product = session.Load<Product>(productID) 
     } 
}; 

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

Для получения дополнительной информации ознакомьтесь с блога Ayende в: The difference between Get, Load, and query by id.

+0

Это здорово! Благодарю.Мне интересно, как я этого раньше не заметил: 0 – UpTheCreek

+0

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

Смежные вопросы