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

IT>>Местный Janus поддерживает 13 СУБД, если не считать принципиальные различия в DB2 LUW vs z/OS и SqlServer 2000 vs 2014. Правда я не уверен, что кому-нибудь понадобиться хостить базу сообщений RSDN на мейнфрейме в DB2 z/OS или SAP HANA. Но, например, в Azure может оказаться хоститься вполне прикольно.

_>Не в курсе кто такой Janus. ))) Но результат отличный!

Читалка местных форумов. Там, конечно, не все базы используются, но насколько мне известно, специфичного для баз данных кода практически нет. Кажется, только при создании БД, чем и ограничено число баз, поставляемых по умолчанию. Но, т.к. вопрос базы данных для linq2db решается на уровне app.config, то подключить любую из поддерживаемых не должно быть проблемой.

_>1. Слой абстракции БД конечно же является не единственным возможным способом обеспечить переносимость (между разными СУБД) кода. Большинство ORM это умеют. Но лично я сомневаюсь в эффективности (быстродействие) такого подхода, т.к. довольно сложно сделать универсальный код эффективным с любой СУБД. В то время как в частных случаях это очевидно делается без проблем.

Вопрос генерации эффективного SQL — это дело техники. Никаких принципиальных ограничений на это нет. Например, пейдджинг практически для всех БД реализован по разному, именно так, как это более эффективно для конкретной БД. Тоже самое с insertOrUpdate. Есть другая проблема. Некоторые БД не подддерживают некоторые возможности, как, например, Sybase не поддерживат TOP в подзапросах. В результате один и тот же linq запрос где-то будет работать, а где-то не очень. В этом случае придётся разруливать всё вручную.

_>2. Слой абстракции БД не имеет своей единственной целью переносимость — он вполне себе встречается в решениях заточенных под одну СУБД, т.к. является архитектурным артефактом.

Слой абстракции БД может нести в себе две функции: абстракцию от БД и абстракцию вообще. Если всё сделано ради первого, а не ради второго, то с использованием linq слой абстракции БД не нужен. При это при его устранении происходит существенное упрощение приложения:

— исчезают pass-through слои и методы,
— исчезают лишние DTO объекты, обеспечивающие ad-hoc запросы
— конкретная логика концентрируется в одном месте, что даёт существенную прибавку к восприятию кода определённую гибкость при его модификации,
— исчезает соблазн повторного использования бизнес-логики, чаще всего приводящего к монструозным методам с десятками параметров и запутанной логикой их использования внутри.

Про главное и самое могучее преимущество linq перед плоским SQL — type-safety, я вообще молчу.

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

IT>>Местный Janus поддерживает 13 СУБД, если не считать принципиальные различия в DB2 LUW vs z/OS и SqlServer 2000 vs 2014. Правда я не уверен, что кому-нибудь понадобиться хостить базу сообщений RSDN на мейнфрейме в DB2 z/OS или SAP HANA. Но, например, в Azure может оказаться хоститься вполне прикольно.

_>Не в курсе кто такой Janus. ))) Но результат отличный!

Читалка местных форумов. Там, конечно, не все базы используются, но насколько мне известно, специфичного для баз данных кода практически нет. Кажется, только при создании БД, чем и ограничено число баз, поставляемых по умолчанию. Но, т.к. вопрос базы данных для linq2db решается на уровне app.config, то подключить любую из поддерживаемых не должно быть проблемой.

_>1. Слой абстракции БД конечно же является не единственным возможным способом обеспечить переносимость (между разными СУБД) кода. Большинство ORM это умеют. Но лично я сомневаюсь в эффективности (быстродействие) такого подхода, т.к. довольно сложно сделать универсальный код эффективным с любой СУБД. В то время как в частных случаях это очевидно делается без проблем.

Вопрос генерации эффективного SQL — это дело техники. Никаких принципиальных ограничений на это нет. Например, пейдджинг практически для всех БД реализован по разному, именно так, как это более эффективно для конкретной БД. Тоже самое с InsertOrUpdate. Есть другая проблема. Некоторые БД не подддерживают некоторые возможности, как, например, Sybase не поддерживат TOP в подзапросах. В результате один и тот же linq запрос где-то будет работать, а где-то не очень. В этом случае придётся разруливать всё вручную.

_>2. Слой абстракции БД не имеет своей единственной целью переносимость — он вполне себе встречается в решениях заточенных под одну СУБД, т.к. является архитектурным артефактом.

Слой абстракции БД может нести в себе две функции: абстракцию от БД и абстракцию вообще. Если всё сделано ради первого, а не ради второго, то с использованием linq слой абстракции БД не нужен. При этом при его устранении происходит существенное упрощение приложения:

— исчезают pass-through слои и методы,
— исчезают лишние DTO объекты, обеспечивающие ad-hoc запросы
— конкретная логика концентрируется в одном месте, что даёт существенную прибавку к восприятию кода и определённую гибкость при его модификации,
— исчезает соблазн повторного использования бизнес-логики, чаще всего приводящего к монструозным методам с десятками параметров и запутанной логикой их использования внутри.

Про главное и самое могучее преимущество linq перед плоским SQL — type-safety, я вообще молчу.