Реализация активных записей в C # - PullRequest
Новая
       7

Реализация активных записей в C #

2 голосов
/ 09 апреля 2011

Я наткнулся на Castle Active Record несколько недель назад и подумал, что это выглядит как интересное решение трудоемких задач CRUD, связанных с приложениями, управляемыми данными.Это кажется довольно зрелым, и я собираюсь использовать его для уровня данных приложения, которое я разрабатываю, но мне было интересно:

  1. Насколько хорошо оно масштабируется?(т.е. хорошо ли масштабируется дополнительный слой над NHibernate)
  2. Каковы его самые большие ограничения, которые вызовут разочарование, если вы слишком далеко зашли в разработку, чтобы легко изменить направление?
  3. Используете ли вы прямой NHibernate безСлой Active Record - лучший долгосрочный вариант?

1 Ответ

4 голосов
/ 09 апреля 2011

Лично я думаю, что сам шаблон Active Record и ребенок Касла определенно имеют некоторые преимущества, такие как:

  • упрощенная конфигурация
  • шаблон AR - «сущность независима».Иногда это просто проект больше всего на свете.
  • Вы можете начать разработку и использовать AR очень быстро в своем проекте.Просто определите правильные отображения, добавьте некоторые настройки, и вы уже можете делать некоторые базовые вещи с сущностями.Эта часть кажется мне быстрее, чем чистый nh.
  • Классы SessionScope + TransactionScope, которые находятся в AR, уже для вас.Это то, что вы должны будете написать сами для nh, если вам, например, необходимо поддерживать наследование транзакций.
  • все проекты Castle просто прекрасно работают вместе.AR + Facilities + Windsor = очень мощный стек.
  • есть новая версия AR (наконец-то!), Которая работает поверх NH 3.0.

Но есть и некоторые недостатки:

  • миф о накладных расходах.Я чувствую, что это не то, что я могу определить, но это просто ощущение, что все это управление сессиями, оболочки и т. Д. Просто должны что-то стоитьНо я думаю, что на самом деле это неуловимо.
  • , если вам нужно сделать что-то нестандартное, вам просто нужно потрогать кишки nhibernate.Это кажется довольно сложным с AR.
  • нет поддержки второго кэша
  • Отображения AR не являются POCO.Может возникнуть проблема при сериализации через WCF или просто при отправке между разными уровнями.Это не так с NH.
  • AR - это не лучший способ форсировать ОО-подход для репозиториев / дао-классов.Но в этом нет ничего нового, потому что это чистое следствие паттерна AR - ваш объект знает, как сохранить или удалить себя.Но это становится болью, когда ваш проект становится немного больше.

Итак, в конце концов, это отличная среда для использования в простых или средних сложных проектах.Это хорошо для asp.net/winforms, не имеет значения.С чистым NH вам определенно придется кодировать намного больше, чтобы создать похожее приложение.Но если вы сделаете это, вы будете намного счастливее.Потому что вы сможете контролировать все.

Как всегда, все зависит от ваших предпочтений или проекта.Для небольших быстрых проектов - AR - это путь, для средних - я бы сказал, NH - это путь!

ps о, кстати, AR делает точно такие же запросы, так что это похоже на использование nh для общения сдб.NH весы и замок тоже.Просто избегайте проблемы «n + 1» и думайте о лени, и вам должно быть хорошо; P

ps слушайте Маурисио Шеффера, он действительно знает, о чем пишет.

...