Каковы за и против использования замка Active Record по сравнению с Прямым NHibernate?
Я думаю, вы ищете то же самое, что я и хотел. Я попытался сделать это, используя разницу в миллисекундах, которую предоставляет javascript, но эти результаты не работают в реальном мире дат. Если вы хотите разницу между 1 февраля 2016 года и 31 января 2017 года, я бы хотел получить 1 год, 0 месяцев и 0 дней. Ровно один год (при условии, что вы считаете последний день как полный день, например, в аренду для квартиры). Тем не менее, миллисекундный подход даст вам 1 год 0 месяцев и 1 день, так как диапазон дат включает високосный год. Итак, вот код, который я использовал в javascript для моей формы adobe (вы можете назвать поля): (отредактирован, произошла ошибка, которую я исправил)
var f1 = this.getField("LeaseExpiration");
var g1 = this.getField("LeaseStart");
var end = f1.value
var begin = g1.value
var e = new Date(end);
var b = new Date(begin);
var bMonth = b.getMonth();
var bYear = b.getFullYear();
var eYear = e.getFullYear();
var eMonth = e.getMonth();
var bDay = b.getDate();
var eDay = e.getDate() + 1;
if ((eMonth == 0)||(eMonth == 2)||(eMonth == 4)|| (eMonth == 6) || (eMonth == 7) ||(eMonth == 9)||(eMonth == 11))
{
var eDays = 31;
}
if ((eMonth == 3)||(eMonth == 5)||(eMonth == 8)|| (eMonth == 10))
{
var eDays = 30;
}
if (eMonth == 1&&((eYear % 4 == 0) && (eYear % 100 != 0)) || (eYear % 400 == 0))
{
var eDays = 29;
}
if (eMonth == 1&&((eYear % 4 != 0) || (eYear % 100 == 0)))
{
var eDays = 28;
}
if ((bMonth == 0)||(bMonth == 2)||(bMonth == 4)|| (bMonth == 6) || (bMonth == 7) ||(bMonth == 9)||(bMonth == 11))
{
var bDays = 31;
}
if ((bMonth == 3)||(bMonth == 5)||(bMonth == 8)|| (bMonth == 10))
{
var bDays = 30;
}
if (bMonth == 1&&((bYear % 4 == 0) && (bYear % 100 != 0)) || (bYear % 400 == 0))
{
var bDays = 29;
}
if (bMonth == 1&&((bYear % 4 != 0) || (bYear % 100 == 0)))
{
var bDays = 28;
}
var FirstMonthDiff = bDays - bDay + 1;
if (eDay - bDay < 0)
{
eMonth = eMonth - 1;
eDay = eDay + eDays;
}
var daysDiff = eDay - bDay;
if(eMonth - bMonth < 0)
{
eYear = eYear - 1;
eMonth = eMonth + 12;
}
var monthDiff = eMonth - bMonth;
var yearDiff = eYear - bYear;
if (daysDiff == eDays)
{
daysDiff = 0;
monthDiff = monthDiff + 1;
if (monthDiff == 12)
{
monthDiff = 0;
yearDiff = yearDiff + 1;
}
}
if ((FirstMonthDiff != bDays)&&(eDay - 1 == eDays))
{
daysDiff = FirstMonthDiff;
}
event.value = yearDiff + " Year(s)" + " " + monthDiff + " month(s) " + daysDiff + " days(s)"
3 ответа
Самый большой про из AR - то, что он дает Вам готовый репозиторий и заботится об управлении сеансами для Вас. Любой из ActiveRecordBase<T> и ActiveRecordMediator<T> является подарком, который Вы закончили бы тем, что собрали сами под NHibernate. Предотвращение отображения XML является другим плюс. Атрибуты отображения AR просты в использовании, все же достаточно гибкие для отображения даже довольно баз данных 'прежней версии'.
самый большой довод "против" AR - то, что он активно поощряет Вас думать неправильно о NHibernate. Таким образом, потому что управление сеансами по умолчанию является сессией на вызов, Вы привыкаете к идее, что сохраненные объекты разъединяются и должны быть Save() d, когда изменения происходят. Это не то, как NHibernate, как предполагается, работает - обычно у Вас были бы session-per-unit-of-work или запрос или поток, и объекты останутся связанными в течение жизненного цикла сессии, таким образом, изменения будут сохранены автоматически. Если Вы начнетесь с помощью AR и затем выясните, что необходимо переключиться на сессию на запрос для создания ленивой работы загрузки - который не хорошо объяснен в документах то - Вы получите противное удивление, когда объект, Вы не ожидали быть сохраненными, сделает, когда сессия сбрасывает.
Принимают во внимание, что команда Замка записала AR как дополнительный продукт для замка Monorail, который является подобной Направляющим платформой для.NET. Это было разработано с этим видом использования в памяти. Это не адаптируется хорошо к более многоуровневому, отделенному дизайну.
Использование это для того, каково это, но не думает об этом как ярлык на NHibernate. Если Вы хотите использовать NH, но постараться не отображать файлы, используйте Атрибуты NHibernate или лучше, Быстрый NHibernate.
Я нашел, что ActiveRecord был хорошей частью набора, и очень подходящий для маленьких/средних проектов, для которых я использовал его. Как направляющие, это принимает много важных решений для Вас, который имеет эффект хранения, Вы сфокусировали Вас на сути проблемы.
, По-моему, pro's и недостатки:
Профессионалы
- Позволяют Вам сфокусироваться на проблеме в руке, потому что много решений приняты для Вас.
- Включает сформировавшиеся, очень применимые классы инфраструктуры (Репозиторий, Проверки и т.д.)
- Запись, что атрибуты AR быстрее, чем запись XML или NHibernate. Отображение. Атрибуты, по моему скромному мнению.
- Хорошая документация и общественная поддержка
- Это - довольно простые в использовании другие функции NHibernate с ним.
- А безопасный запуск. У Вас есть вынимать пункт. Можно медленно отступать в сделанное на заказ решение NHibernate, если Вы врезаетесь в стены с AR.
- Большой для доменной первой разработки (генерирующий дб).
- Вы могли бы также хотеть искать преимущества и недостатки шаблон ActiveRecord
Недостатки
- , Вы не можете притвориться, что NHibernate не там - все еще необходимо изучить это.
- не Могло бы быть настолько продуктивным, если у Вас уже есть унаследованная база данных для работы с.
- Не прозрачная персистентность.
- Встроенные отображения являются всесторонними, но для приблизительно проекты Вы, возможно, должны были бы вернуться к отображениям NHibernate в местах. У меня не было этой проблемы, но просто мысли.
В целом, мне действительно нравится ActiveRecord, и он всегда экономил время, главным образом потому что я кажусь счастливо , принимают решения и инструменты, испеченные в библиотеку, и впоследствии проводят больше времени, фокусируясь на проблеме в руке.
я дал бы ему попытку на нескольких проектах и видел бы то, что Вы думаете.
Когда я начал использовать NHibernate, я не узнал о замке ActiveRecord, пока я не записал свои файлы Отображения и сделал мои классы. В той точке я не мог явно различить то, что замок Activerecord даст мне, таким образом, я не использовал его.
Во второй раз, когда я использовал NHibernate, я просто использовал myGeneration для создания отображающихся файлов и классов только при наличии, это смотрит на мою базу данных. Это сэкономило много времени отдельно и позволило мне (еще раз) не, волнуются о замке Active Record.
В действительности, большая часть Вашего времени будет потраченным созданием пользовательских запросов, и замок Active Record не обязательно поможет с тем - если бы необходимо было использовать myGeneration с NHibernate, то Вы обошли бы большую часть работы, которую необходимо было бы сделать так или иначе.
Редактирование: Я не хочу походить на ярого сторонника или myGeneration или NHibernate. Я просто использую инструмент, который позволяет мне делать свою работу быстро и легко. Чем меньше времени я имею для расходов кода Доступа к данным написания, тем лучше. Это не означает, что я не могу сделать этого - но существует мало смысла в изобретении велосипед каждый раз, когда Вы пишете новое приложение. Еще запишите SQL-запросы и Хранимые процедуры при необходимости, и не где. При выполнении операций CRUD ORM является способом пойти.
Редактирование № 2: замок Active Record может принести больше к таблице, чем я понимаю - я не знаю много другой , чем, что находится на их веб-сайте , но если бы это действительно приносит больше к таблице, затем это помогло бы потенциальным приемным родителям смочь с готовностью видеть это на своем сайте.