Комментарии 19
Это код можно использовать только как прототип, если осмелитесь пустить оставить это в production, то вас посадят за растрату (копайте в сторону reflection).
А как быть в случае хранимок с параметрами? например sp_GetBooksByAuthor?
Как то у вас все запутано, везде хранимые процедуры, пусть на них все мапится… откуда такая предвзятость?
и уж тем более знать имена сторед процедур надо везде с вашим подходом, какой же это мапинг?
а в чем собственно проблема с именами процедур? если совсем не хочеться хардкодить строку с именем то можно реализовать метод для построения имени процедуры, опять таки используя рефлексию брать имя класса-сущности например, а под маппингом я понимаю наложение результата процедуры на класс модели
как то это по моему геморойно все
попробуйте линктусиквел, посмотрите какие запросы он генерирует
посчитайте время которое вы затрачиваете на то что бы сделать свои хранимые процедуры (которых у вас катастрофически много будет получаться кстати с вашим подходом) и время которое понадобиться сделать это например с линкью
а потом посмотрите на сколько реально будет выигрыш в производительности у вашего подхода
вообще овчинка стоит выделки? по моему нет
тем более у вас пока не видно удобной работы со связными сущностями
а начнете думать как это сделать, и опять получится линкью или еф =)
попробуйте линктусиквел, посмотрите какие запросы он генерирует
посчитайте время которое вы затрачиваете на то что бы сделать свои хранимые процедуры (которых у вас катастрофически много будет получаться кстати с вашим подходом) и время которое понадобиться сделать это например с линкью
а потом посмотрите на сколько реально будет выигрыш в производительности у вашего подхода
вообще овчинка стоит выделки? по моему нет
тем более у вас пока не видно удобной работы со связными сущностями
а начнете думать как это сделать, и опять получится линкью или еф =)
как уже писал что мне не нравиться linqtosql так как сложный запрос вы на нем не напишете, проект не большой и процедур будет всего 2-3 десятка, чем процедуры лучше запросов генерируемых линкью я уже писать не буду, думаю это и так поятно, для небольший проектов этот метод подойдет очень хорошо, если проект большой то лучше использовать Entity Framework, linqtosql лучше неиспользовать совсем. (из своего опыта, так как сейчас пишу проект использующий linqtosql)
а что за запрос вы на нем не напишете? можно пример?
а по поводу EF — его можно и на маленьких проектах использовать
проблема основная которую вижу я — это неправильное их (линкью и еф) использование
они реализуют паттерн еденица работы, а их пытаются делать синглтонами и оч много бед и глюков из за этого
но все таки приведите пример что у вас не получается сделать с линкью?
а по поводу EF — его можно и на маленьких проектах использовать
проблема основная которую вижу я — это неправильное их (линкью и еф) использование
они реализуют паттерн еденица работы, а их пытаются делать синглтонами и оч много бед и глюков из за этого
но все таки приведите пример что у вас не получается сделать с линкью?
ммм, как-то интересно. А разве linq2sql не поддерживает хранимки? Какие сложные запросы, о чем Вы? весь запрос у Вас в хранимке, вот и вызывайте ханимку с помощью linq2sql
Если в хранимке результат выводиться из временных таблиц или табличной перевенной то линкью не сгенерирует правильно dbml файл, описывать класс со структурой и наполнением прийдется всеравно руками, во вторых если использоыввать хранимки то зачем вообще тогда нужен линкью? проще написать хелпер метод как в статье и юзать его без всяких линкью, или вы используете всегда технологию лиш бы было, особо не разбираясь нужна ли такая функциональность в проекте или нет?
Всё-таки использование nHibernate или Entity Framework упростило бы вам жизнь.
Использовать NH или EF на проекте с пару десяткой процедур и таблиц это все равно что с пушки по воробьям
А создать пару десятков своих велосипедов и затем их поддерживать проще? Тот же nHibernate в освоении очень прост. За несколько часов можно разобраться и прикрутить к проекту.
Всеравно я не согласен с Вами, надо понимать когда нужно писать свой велосипед, а когда лучше взять готовое решение типа NH, а бездумно пихать эти решения где только возможно это не совсем правильно
т.е. вы считаете, что проект, имеющий «пару десяток процедур и таблиц», недостаточно большой по объёму, чтобы переложить все хлопоты по манипуляции с бизнес сущностями на orm, а возиться руками и тратить на это время? Да и переносить бизнес логику на слой DA не всегда дело благодарное.
Я согласен, что пихать мощные штуки куда хочется не надо, но в описанной вами ситуации я бы прикрутил orm.
Я согласен, что пихать мощные штуки куда хочется не надо, но в описанной вами ситуации я бы прикрутил orm.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ORM или простое наполнение класса данными из хранимой процедуры