Здравствуйте.
На форумах часто пишут, что ORM(EF, L2S, NH) в основном хорошо подходят для небольших и средних проектов.
Отсюда вытекает вопрос, как организовать доступ к БД для больших проектов.

Здравствуйте, _ichensky, Вы писали:

_>Здравствуйте.
_>На форумах часто пишут, что ORM(EF, L2S, NH) в основном хорошо подходят для небольших и средних проектов.
_>Отсюда вытекает вопрос, как организовать доступ к БД для больших проектов.
Что такое небольшой, средний и большой проект?
Почему ОРМ не подходят для "больших" на форумах пишут?

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>Почему ОРМ не подходят для "больших" на форумах пишут?

Большой проект: напр. система по продаже жд,авиа билетов для всей страны.

Не подходят, потому что размазывают логику доступа к БД по всему проекту + генерируют sql, который не всегда оптимален + медленные + кеширование для большого проекта надо делать вручную.
Из плюсов для большого проекта из orm можно выделить мапинг.

Здравствуйте, _ichensky, Вы писали:


_>Большой проект: напр. система по продаже жд,авиа билетов для всей страны.


А что в этой системе большого? Данных мало, логика простая, нагрузка так себе, кэшируется все прекрасно.
Тут ОРМ не нужен скорее из-за простоты хранения.

Здравствуйте, _ichensky, Вы писали:

_>Большой проект: напр. система по продаже жд,авиа билетов для всей страны.

А если для города — то маленький?

_>Не подходят, потому что размазывают логику доступа к БД по всему проекту

Не размазывайте.

_>генерируют sql, который не всегда оптимален

Вот это есть. Но если опасения по этому поводу сильные — выделите ORM в DAL с Repository или QueryObject. В начале получите рабочий проект более быстро, а после переделаете под "голый" SQL с минимумом изменений в BL.

Здравствуйте, _ichensky, Вы писали:

A>>Почему ОРМ не подходят для "больших" на форумах пишут?

_>Большой проект: напр. система по продаже жд,авиа билетов для всей страны.
Что-то мне кажется, что под большим проектом имеется ввиду высоконагруженны? Я прав?

Если копнуть в сторону ORM, то может оказаться что не все ОРМ одинаковые, и что кроме большой и неповоротливой тройки EF, L2S, NH (озвученной выше), есть и более простые и быстрые решения (еще) решения, есть даже такое.
Но! Чем выше скорость, тем меньше "плюшек", которые предоставляет ОРМ.

Для меня главные плюсы ОРМ это мапинг и linq, поэтому bltoolkit и linq2db это именно то что мне надо от ОРМ (linq2db не пробовал, но должно быть именно то что нужно: bltoolkit, но проще).


_>Не подходят, потому что размазывают логику доступа к БД по всему проекту
По мне так наоборот -- концентрируют возле модели.

_> + генерируют sql, который не всегда оптимален
Большие и сложные sql обычно нужны для отчетов, если нужна еще и скорость, то бывает длаже ручного sql не достаточно, приходится специально готовить данные для выборки.
На моей же практике, bltoolkit отлично справлялся со сложными linq запросами к большой базе (несколько десятков гигабайт данных), медленные запросы отлично тюнились индексами и специальными вычисляемыми полями специально для поиска

_> + медленные
См выше, про разные ОРМ.

_>+ кеширование для большого проекта надо делать вручную.
Какое именно и чего кэширование имеется ввиду и почему без ОРМ его не нужно делать вручную?

СУВ, Aikin

Здравствуйте, _ichensky, Вы писали:

_>Здравствуйте.
_>На форумах часто пишут, что ORM(EF, L2S, NH) в основном хорошо подходят для небольших и средних проектов.
_>Отсюда вытекает вопрос, как организовать доступ к БД для больших проектов.

Имхо ORM применим не к проекту, а к области. обойтись без ORM в каком-нить анализаторе статистики и т.д. будет сложно и затруднит проект. А вот в процессинге использование ORM напрочь убьет производительность, потому что в нем очень много логики, которая лежит как на стороне приложения так и в базе.

Здравствуйте, Aikin, Вы писали:

A>>>Почему ОРМ не подходят для "больших" на форумах пишут?

_>>Большой проект: напр. система по продаже жд,авиа билетов для всей страны.
A>Что-то мне кажется, что под большим проектом имеется ввиду высоконагруженны? Я прав?

SE — достаточно высоко нагруженый или нет?

Здравствуйте, _ichensky, Вы писали:

_>Здравствуйте.
_>На форумах часто пишут, что ORM(EF, L2S, NH) в основном хорошо подходят для небольших и средних проектов.
_>Отсюда вытекает вопрос, как организовать доступ к БД для больших проектов.
Не решай проблемы, которых нет.

У тебя нет большого и, тем более, высоконагруженного проекта. И когда не будет.
А если появится, то первое, во что ты упрешься — неоптимальность схемы, лечится индексами\вьюхами\тригеррами.
Второе, во что ты упрешься — объем данных, который надо перекачивать между приложением и БД, лечится правильным кешированием.
Третье, во что ты упрешься — масштабирование БД...
До проблем с ОРМ не доживешь, если очередно StackOverflow не сделаешь.

Ну это если ты не будешь всякими DDD заниматься.

Здравствуйте, Yoriсk, Вы писали:

_>>>Большой проект: напр. система по продаже жд,авиа билетов для всей страны.
A>>Что-то мне кажется, что под большим проектом имеется ввиду высоконагруженны? Я прав?

Y>SE — достаточно высоко нагруженый или нет?
Достаточно для чего?

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>>>Что-то мне кажется, что под большим проектом имеется ввиду высоконагруженны? Я прав?
Y>>SE — достаточно высоко нагруженый или нет?
A>Достаточно для чего?

Для того, что-бы гордо нести звание "высоконагруженого".

A>СУВ, Aikin

СУВ, Капитан О.

Здравствуйте, Yoriсk, Вы писали:

A>>>>Что-то мне кажется, что под большим проектом имеется ввиду высоконагруженны? Я прав?
Y>>>SE — достаточно высоко нагруженый или нет?
A>>Достаточно для чего?

Y>Для того, что-бы гордо нести звание "высоконагруженого".
Чё сказать-то хотел?