Разве там серьезные основания не состоят в том, чтобы использовать ORM? [закрытый]
Вы имели в виду нечто подобное? (работает для Bokeh v1.0.4)
import pandas as pd
import numpy as np
from bokeh.models import ColumnDataSource
from bokeh.plotting import figure, show
bools = [0, 1, 0, 0, 1, 1, 0, 1, 1, 0, 0, 1]
colors = ['red' if bool == 0 else 'blue' for bool in bools]
df = pd.DataFrame(data = np.random.rand(len(bools), 1), columns = ['close_price'], index = pd.date_range(start = '01-01-2015', periods = len(bools), freq = 'd'))
xs, ys = [], []
for xs_value, ys_value in zip(df.index.values, df['close_price'].values):
if len(xs) > 0 and len(ys) > 0:
xs.append([xs[-1][1], xs_value])
ys.append([ys[-1][1], ys_value])
else:
xs.append([xs_value, xs_value])
ys.append([ys_value, ys_value])
source = ColumnDataSource(dict(xs = xs, ys = ys, color = colors))
p = figure(width = 500, height = 300, x_axis_type = "datetime")
p.multi_line(xs = 'xs',
ys = 'ys',
color = 'color',
source = source,
line_width = 3)
show(p)
Результат:
3 ответа
Я предлагаю это чтение для списка недостатков ORM.
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
Я обнаружил, что ORM очень полезны для большинства приложений. написано!
/ Asger
Мой опыт работы с Hibernate заключается в том, что его семантика неуловима, и когда возникают проблемы, немного трудно понять, что происходит не так. капот. Я слышал от друга, что часто начинают с критериев, затем нужно немного больше гибкости и HQL, а позже замечают, что в конце концов нужен необработанный SQL (например, Hibernate не имеет объединения AFAIK).
Также с ORM люди легко склонны чрезмерно использовать существующие сопоставления / модели, что приводит к тому, что существует объект с множеством атрибутов, которые не инициализированы. Поэтому после запроса внутри транзакции Hibernate выполняет дополнительную выборку данных, что может привести к замедлению. К сожалению, объект модели hibernate иногда просачивается на уровень архитектуры представления, а затем мы видим LazyInitializationExceptions.
Чтобы использовать ORM, нужно действительно понимать это. К сожалению, легко создается впечатление, что это просто, а это не так.
Золотая середина ORM
ORM полезны для автоматизации более 95% запросов, где они применимы. Их особая сила в том, что у вас есть приложение с сильной архитектурой объектной модели и база данных, которая хорошо сочетается с этой объектной моделью. Если вы делаете новую сборку и имеете сильные навыки моделирования в своей команде, вы, вероятно, получите хорошие результаты с ORM.
У вас может быть несколько запросов, которые лучше выполнять вручную. В этом случае не бойтесь написать несколько хранимых процедур, чтобы справиться с этим. Даже если вы намереваетесь перенести свое приложение на несколько платформ СУБД, код, зависящий от базы данных, будет в меньшинстве. Принимая во внимание, что вам нужно будет протестировать свое приложение на любой платформе, на которой вы собираетесь его поддерживать, небольшие дополнительные усилия по переносу некоторых хранимых процедур не сильно повлияют на вашу совокупную стоимость владения. В первом приближении 98% переносимость так же хороша, как и 100% переносимость, и намного лучше, чем запутанные или плохо работающие решения для обхода ограничений ORM.
Я видел, что первый подход хорошо работает в очень большом (100 человеко-лет) проекте J2EE.
Где ORM может не подходить наилучшим образом
В других случаях могут быть подходы, которые подходят приложению лучше, чем ORM. В книге Фаулера «Шаблоны архитектуры корпоративных приложений» есть раздел о шаблонах доступа к данным, который неплохо справляется с каталогизацией различных подходов к этому.Я видел несколько примеров ситуаций, в которых ORM может быть неприменим:
В приложении с обширной устаревшей кодовой базой хранимых процедур вы можете захотеть использовать функционально ориентированные (не путать с функциональными языками) данные слой доступа для наматывания действующих звездочек. Это повторно использует существующий (и, следовательно, протестированный и отлаженный) уровень доступа к данным и дизайн базы данных, что часто представляет собой довольно существенные усилия по разработке и тестированию, и позволяет избежать необходимости переноса данных в новую модель базы данных. Часто это хороший способ обернуть слои Java вокруг устаревших баз кода PL / SQL или перенастроить полнофункциональные клиентские приложения VB, Powerbuilder или Delphi с помощью веб-интерфейсов.
Вариант - это когда вы наследуете модель данных, которая не обязательно хорошо подходит для сопоставления O-R. Если (например) вы пишете интерфейс, который заполняет или извлекает данные из внешнего интерфейса, вам может быть лучше работать напрямую с базой данных.
Финансовые приложения или другие типы систем, в которых важна межсистемная целостность данных, особенно если вы используете сложные распределенные транзакции с двухфазной фиксацией. Возможно, вам придется управлять своими транзакциями лучше, чем это может поддерживать ORM.
Высокопроизводительные приложения, в которых вы действительно хотите настроить доступ к базе данных. В этом случае может быть предпочтительнее работать на более низком уровне.
Ситуации, когда вы используете существующий механизм доступа к данным, такой как ADO.Net, который «достаточно хорош» и хорошо работает с платформой, приносит большую пользу, чем ORM.
Иногда данные - это просто данные - это может быть случай (например), что ваше приложение работает с «транзакциями», а не с «объектами», и это разумное представление о предметной области. Примером этого может быть финансовый пакет, в котором у вас есть транзакции с настраиваемыми полями анализа. Хотя само приложение может быть построено на платформе O-O, оно не привязано к одной модели бизнес-области и может не знать гораздо больше, чем коды GL, учетные записи, типы документов и полдюжины полей анализа. В этом случае приложение не знает о модели бизнес-домена как таковой, а объектная модель (за пределами самой структуры реестра) не имеет отношения к приложению.