Генераторы кода по сравнению с ORMs по сравнению с Хранимыми процедурами
Начиная с Spring 3.0, вы можете добавить строку, как
, к вашему applicationContext.xml (или где вы настраиваете вещи). Как отмечает Дмитрий Чорный в комментарии, конфигурация на основе Java выглядит так:
@Bean public ConversionService conversionService() {
return new DefaultConversionService();
}
Это активирует новую службу конфигурации, которая поддерживает преобразование типов String в Collection. Если вы не активируете эту конфигурационную службу, Spring отказывается от своих устаревших редакторов свойств в качестве служб конфигурации, которые не поддерживают такой тип преобразования.
Также работает преобразование в коллекции других типов:
@Value("${my.list.of.ints}")
private List myList
будет работать с линией, подобной
my.list.of.ints= 1, 2, 3, 4
Нет проблем с пробелом там, ConversionServiceFactoryBean позаботится об этом.
В приложении Spring, вы обычно настраиваете экземпляр ConversionService на контейнер Spring (или ApplicationContext). Этот ConversionService будет выбран весной, а затем использоваться всякий раз, когда преобразование типа должно выполняться каркасом. [...] Если ConversionService не зарегистрирована в Spring, используется исходная система на основе PropertyEditor.
blockquote>
6 ответов
Каждые из этих инструментов обеспечивают отличающиеся слои абстракции, наряду с отличающимися точками для переопределения поведения. Это возможности выбора архитектуры, и все варианты архитектуры зависят от компромиссов между технологией, управлением, и организацией, обоими из самого приложения и среды, где это будет развернуто.
-
, Если Вы имеете дело с культурой, где DBAs 'управляет насест', затем основанную на хранимой процедуре архитектуру будет легче развернуть. С другой стороны, может быть очень трудно управлять и присвоить версию хранимым процедурам.
-
Генераторы кода сияют при использовании статически типизированных языков потому что можно зафиксировать ошибки во время компиляции вместо во времени выполнения.
-
ORMs идеальны для инструментов интеграции, где Вы, возможно, должны иметь дело с другим RDBMSes и схемами на основе от установки к установке. Измените одну карту, и Ваше приложение идет от работы с PeopleSoft на Oracle к работе с Microsoft Dynamics на SQL Server.
я видел приложения, где Сгенерированный Код используется для взаимодействия через интерфейс с Хранимыми процедурами, потому что хранимые процедуры можно было настроить для обхождения ограничений в генераторе кода.
В конечном счете единственный корректный ответ будет зависеть от проблемы, которую Вы пытаетесь решить и среда, где решение должно выполниться. Что-либо еще обсуждает корректное произношение 'картофеля'.
Я добавлю свои два цента:
Хранимые процедуры
- Могут быть легко оптимизированы
- , Абстрактные фундаментальные бизнес-правила, улучшая целостность данных
- Обеспечивают хорошую модель обеспечения безопасности (никакая потребность предоставить чтение или полномочия записи переднему пользователю дб направления)
- Сияние, когда у Вас есть много приложений, получающих доступ к тем же данным
, ORMs
- Позволил Вам сконцентрироваться только на домене и иметь более "чистый" объектно-ориентированный подход для разработки
- Сияние, когда Ваше приложение должно быть перекрестным дб, совместимым
- Сияние, когда Ваше приложение главным образом управляется поведением вместо данных
, Генераторы кода
- Предоставляют Вам подобные преимущества как ORMs, с более высокими затратами на обслуживание, но с лучшей настраиваемостью.
- обычно превосходят ORMs в этом, ORMs имеют тенденцию обменивать ошибки времени компиляции на ошибки периода выполнения, которого нужно обычно избегать
Я соглашаюсь, что существуют за и против ко всему, и много зависит от Вашей архитектуры. Однако я пытаюсь использовать ORM's, где он имеет смысл. Большая функциональность уже там, и обычно они помогают предотвратить Внедрение SQL (плюс он, помогает постараться не изобретать велосипед).
см. эти другие два сообщения по теме (динамический SQL по сравнению с хранимыми процедурами по сравнению с ORM) для получения дополнительной информации
Динамический SQL по сравнению с хранимыми процедурами
, Который лучше: Специальные запросы или хранимые процедуры?
ORMs по сравнению с хранимыми процедурами
, Почему параметризованный SQL сгенерирован NHibernate настолько же быстро как хранимая процедура?
ORMs и генераторы кода находятся отчасти на одной стороне поля, и хранимые процедуры находятся на другом. Как правило, легче использовать ORMs и генераторы кода в проектах нового строительства, потому что можно адаптировать схему базы данных для соответствия модели предметной области, которую Вы создаете. Намного более трудно использовать их с проектами прежней версии, потому что, после того как программное обеспечение записано с "данными сначала" мышление, трудно перенести его с моделью предметной области.
Однако все три из подходов имеют значение. Хранимые процедуры может быть легче оптимизировать, но может быть заманчиво поместить бизнес-логику в них, которые могут быть повторены в самом приложении. ORMs работают хорошо, если Ваша схема соответствует понятию ORM, но может быть трудной настроить если нет. Генераторы кода могут быть хорошим вторым планом, потому что они предоставляют некоторые преимущества ORM, но позволяют настройку сгенерированного кода - однако, если Вы вырабатываете привычку изменения сгенерированного кода, у Вас затем есть две проблемы, потому что необходимо будет изменить его каждый раз, когда Вы повторно создаете его.
нет никакого истинного ответа, но я склоняюсь больше к стороне ORM, потому что я полагаю, что имеет больше смысла думать с объектным первым мышлением.
Хранимые процедуры
- Профессионалы: Инкапсулирует код доступа к данным и не зависящий от приложения
- Недостатки: Может быть определенным для RDBMS и увеличить время разработки
ORM
, который По крайней мере некоторые ORMs позволяют отображать на хранимые процедуры
- Профессионалы: код доступа к данным Кратких обзоров и позволяет объектам объекта быть записанными проблемно-ориентированным способом
- Недостатки: Возможная производительность наверху и ограниченная отображающаяся возможность
Генерация кода
- Профессионалы: Может использоваться, чтобы сгенерировать сохраненный-proc базирующийся код или ORM или соединение оба
- Недостатки: слой Генератора кода, вероятно, придется сохраняться в дополнение к пониманию сгенерированного кода
Вы забыли значительную опцию, которая заслуживает собственной категории: гибридная платформа отображения данных такой как iBatis.
я был доволен iBatis, потому что он позволяет Вашему OO кодировать, остаются OO по своей природе, и Ваша база данных остается реляционной по своей природе, и решает несоответствие импеданса путем добавления третьей абстракции (отображающийся слой между объектами и отношениями), который ответственен за отображение этих двух, вместо того, чтобы пробовать к глухой посадке одну парадигму в другой.