У нас в конторе почти с каждым новым проектом новая ORM. Юзали .netTiers, DataTables и LINQ. По сравнению с LINQ, все остальное для меня теперь лишнее повышение сложности. А как говорит Макконнелл, борьба с ней это главный технический императив Дак вот, очередной проект и наш архитектор решил использовать очередную ORM под названием PLINQO То есть опять же генерация сущностей при любом изменении базы Обоснование использования привел как наличие встроенных функций по типу GetByForeignKey, но ведь в линке это всего пару строчек, там и так отличное обращение ко всем связанным таблицам. Но это было бы еще пол беды Вторая цель введения ORM — изолировать работу с БД. Пользоваться линкой напрямую из кода запрещено, если надо выполнить запрос к бд, то надо создать отдельный метод в менеджере данной таблицы(эта орм генерирует менеджер для каждой таблицы) и уже вызывать его. Для каждого запроса отдельный метод! Встает вопрос как из метода вернуть анонимный тип? В качестве решения выбрали возвращать object, из него поля конечно просто так не вытащишь, но при биндинге работает...

Уважаемые архитекторы, проясните для меня ситуацию, может наш архитектор прав и не стоит использовать линк в коде, а писать для каждой операции отдельный метод?

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

H>Уважаемые архитекторы, проясните для меня ситуацию, может наш архитектор прав и не стоит использовать линк в коде, а писать для каждой операции отдельный метод?

Трудно сказать. Изначально DAL возник как способ изоляции работы со строковой генерацией SQL. Всё помещается в отдельный слой, который возвращает и принимает только тпипзированные в терминах приложения данные. Идея правильная, перешедшая постепенно в разряд гигиенических, как чистить зубы. Но если зубы убрать и рот зашить, то как бы и чистить нечего. Так же и с LINQ. LINQ устраняет первоначальную проблему, из-за которой DAL выделяется в отдельный слой, а именно проблему работы с нетипизированными сущностями. В результате с этой точки зрения DAL не имеет смысла.

Но существуют и другие эффекты, которые даёт разбиение на слои. Причём как пложительные, так и отрицательные. Положительные — расслоение позволяет несколько лучше структуризировать код, отрицательные — расслоение часто приводит к возникновению массы pass-through методов, которые кроме замусоривания кода ни к чему другому не приводят.

Поэтому, нужен ли DAL при использовании LINQ трудно сказать. Однозначно сказать можно будет только попробовав и тот и другой способ. Лично я собираюсь в самое ближайшее время поэкспериментировать и попытаться обойтись без DAL. Посмотрим что из этого выйдет

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

Сложный вопрос, отчасти религиозный.
Прежде всего о терминах. Общепринятого понимания, что такое ORM, нет. К примеру, Хейлсберг считает что Linq2SQL это все же ORM.
Разница же между всякими Hibernate и Linq2SQL состоит в том, что первый меняет модель данных, второй нет. Отсюда все различия — в первом случае получаем близкую к ООП структуру персистентных данных, во втором эта структура остается реляционной. Понятно, что в первом случае нужно выполнять много работы по преобразованию моделей.
Что выбрать? Вопрос вкуса архитектора больше. Лично я все же предпочитаю оставаться в рамках реляционной модели — усилия по борьбе с преобразованием моделей на моих проектах как правило не окупаются.

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

IT>Поэтому, нужен ли DAL при использовании LINQ трудно сказать. Однозначно сказать можно будет только попробовав и тот и другой способ. Лично я собираюсь в самое ближайшее время поэкспериментировать и попытаться обойтись без DAL. Посмотрим что из этого выйдет

У меня есть такой опыт. В маленьких приложениях выходит хорошо, в более крупных — неочень. Использование Linq2SQL запросов к БД праямо в слое бизнес-логики сильно снижает тестируемость кода.
Недостатки можно обойти, создав "легковесный DAL" — класс (классы) со свойствами, возвращающими IQueryable.

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

G>У меня есть такой опыт. В маленьких приложениях выходит хорошо, в более крупных — неочень. Использование Linq2SQL запросов к БД праямо в слое бизнес-логики сильно снижает тестируемость кода.

А как наличие DAL как отдельного слоя сильно повышает тестируемость кода?

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

G>>У меня есть такой опыт. В маленьких приложениях выходит хорошо, в более крупных — неочень. Использование Linq2SQL запросов к БД праямо в слое бизнес-логики сильно снижает тестируемость кода.
IT>А как наличие DAL как отдельного слоя сильно повышает тестируемость кода?
Да. Можно использовать моки, например.

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

C>Да. Можно использовать моки, например.

Моки для IQueryable? Ну, теоретически, наверное, можно. А на практике такие моки потянут минимум на несколько человекомесяцев.

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

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

C>>Да. Можно использовать моки, например.

AVK>Моки для IQueryable? Ну, теоретически, наверное, можно. А на практике такие моки потянут минимум на несколько человекомесяцев.
Это вы слишком плохо о Linq думаете. У IEnumerable есть метод AsQueryable.
Поэтому моки делаются очень просто.

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

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

G>>У меня есть такой опыт. В маленьких приложениях выходит хорошо, в более крупных — неочень. Использование Linq2SQL запросов к БД праямо в слое бизнес-логики сильно снижает тестируемость кода.

IT>А как наличие DAL как отдельного слоя сильно повышает тестируемость кода?
Ну если бизнес-слой напрямую обращается к базе, то протестировать его без базы становится невозможно. Подготовка и загрузка в БД тестовых данных для каждого теста может выполняться очень долго.
В проекте, где не было DAL в отдельном слое, 40 тестов выполнялись около 3 минут. Естественно разработчики их запускали очень редко.

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

IT>Трудно сказать. Изначально DAL возник как способ изоляции работы со строковой генерацией SQL. Всё помещается в отдельный слой, который возвращает и принимает только тпипзированные в терминах приложения данные. Идея правильная, перешедшая постепенно в разряд гигиенических, как чистить зубы. Но если зубы убрать и рот зашить, то как бы и чистить нечего. Так же и с LINQ. LINQ устраняет первоначальную проблему, из-за которой DAL выделяется в отдельный слой, а именно проблему работы с нетипизированными сущностями. В результате с этой точки зрения DAL не имеет смысла.

IT>Но существуют и другие эффекты, которые даёт разбиение на слои. Причём как пложительные, так и отрицательные. Положительные — расслоение позволяет несколько лучше структуризировать код, отрицательные — расслоение часто приводит к возникновению массы pass-through методов, которые кроме замусоривания кода ни к чему другому не приводят.

IT>Поэтому, нужен ли DAL при использовании LINQ трудно сказать. Однозначно сказать можно будет только попробовав и тот и другой способ. Лично я собираюсь в самое ближайшее время поэкспериментировать и попытаться обойтись без DAL. Посмотрим что из этого выйдет

Спасибо за развернутый ответ, как я понял общепринятого подхода на этот случай пока не существует. Попробуем писать как сказал архитектор, если подход окажется нерациональным значит он сам себя и похоронит.

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

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

AVK>Сложный вопрос, отчасти религиозный.
AVK>Прежде всего о терминах. Общепринятого понимания, что такое ORM, нет. К примеру, Хейлсберг считает что Linq2SQL это все же ORM.
AVK>Разница же между всякими Hibernate и Linq2SQL состоит в том, что первый меняет модель данных, второй нет. Отсюда все различия — в первом случае получаем близкую к ООП структуру персистентных данных, во втором эта структура остается реляционной. Понятно, что в первом случае нужно выполнять много работы по преобразованию моделей.
AVK>Что выбрать? Вопрос вкуса архитектора больше. Лично я все же предпочитаю оставаться в рамках реляционной модели — усилия по борьбе с преобразованием моделей на моих проектах как правило не окупаются.

Да, я тоже считаю что Linq2SQL это ORM, все таки любые данные можно вытянуть с помощью одной строки + поддержка связаных сущностей. Значит вы используйте linq запросы прямо в коде, я все таки тоже склоняюсь к мнению что для линки отдельный слой для доступа к бд является избыточным.

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

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

IT>>Поэтому, нужен ли DAL при использовании LINQ трудно сказать. Однозначно сказать можно будет только попробовав и тот и другой способ. Лично я собираюсь в самое ближайшее время поэкспериментировать и попытаться обойтись без DAL. Посмотрим что из этого выйдет

G>У меня есть такой опыт. В маленьких приложениях выходит хорошо, в более крупных — неочень. Использование Linq2SQL запросов к БД праямо в слое бизнес-логики сильно снижает тестируемость кода.
G>Недостатки можно обойти, создав "легковесный DAL" — класс (классы) со свойствами, возвращающими IQueryable.

Вопрос к вам, если вы возвращаете IQueryable, то с биндингом проблем никаких не будет, а как поступаете если нужно добраться до полей которые создаются в анонимном типе?

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

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

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

IT>>>Поэтому, нужен ли DAL при использовании LINQ трудно сказать. Однозначно сказать можно будет только попробовав и тот и другой способ. Лично я собираюсь в самое ближайшее время поэкспериментировать и попытаться обойтись без DAL. Посмотрим что из этого выйдет

G>>У меня есть такой опыт. В маленьких приложениях выходит хорошо, в более крупных — неочень. Использование Linq2SQL запросов к БД праямо в слое бизнес-логики сильно снижает тестируемость кода.
G>>Недостатки можно обойти, создав "легковесный DAL" — класс (классы) со свойствами, возвращающими IQueryable.

H>Вопрос к вам, если вы возвращаете IQueryable, то с биндингом проблем никаких не будет, а как поступаете если нужно добраться до полей которые создаются в анонимном типе?
Я имел ввиду IQueryable<T>

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

IT>>А как наличие DAL как отдельного слоя сильно повышает тестируемость кода?
G>Ну если бизнес-слой напрямую обращается к базе, то протестировать его без базы становится невозможно. Подготовка и загрузка в БД тестовых данных для каждого теста может выполняться очень долго.
G>В проекте, где не было DAL в отдельном слое, 40 тестов выполнялись около 3 минут. Естественно разработчики их запускали очень редко.

Значит такие тесты были.

В правильно спроектированном приложении 80% методов бизнес логики — это pass-through методы. А для оставшихся 20% как раз интересует как оно там правильно легло в базу. Что тогда в бизнес логике тестировать без DAL?

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

IT>В правильно спроектированном приложении 80% методов бизнес логики — это pass-through методы.
А кто данные получать из базы и передавать в эти методы будет?
Как ни крути, а без DAL другие слои будут завязаны на БД, и протестировать их без БД не получится.

IT>А для оставшихся 20% как раз интересует как оно там правильно легло в базу.
Наверное всетаки интересует не "как" легло, а "что" легло. Это "что" вполне можно тестировать без БД.

IT>Что тогда в бизнес логике тестировать без DAL?
Собственно саму логику.

Если логики нет и все приложение сводится к изменению записи в БД в ответ на действия пользователя, то тестирование там не нужно. Там нужно что-то типа Dynamic Data.

ЗЫ В другом проектке с использованием "легковесного DAL" почти вся логика тестируется без БД.

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

IT>>В правильно спроектированном приложении 80% методов бизнес логики — это pass-through методы.
G>А кто данные получать из базы и передавать в эти методы будет?

Потребитель

G>Как ни крути, а без DAL другие слои будут завязаны на БД, и протестировать их без БД не получится.

Мой вопрос как раз "зачем?" тестировать другие слои без БД если эти слои на 100% завязаны на БД.

IT>>А для оставшихся 20% как раз интересует как оно там правильно легло в базу.
G>Наверное всетаки интересует не "как" легло, а "что" легло. Это "что" вполне можно тестировать без БД.

"Что" ты передаёшь в DAL, зачем это тестировать ещё раз? А вот "как" легло? Сработали ли констрейны, тригеры (боже упаси), чего там нагенерировало identity и т.п.

IT>>Что тогда в бизнес логике тестировать без DAL?
G>Собственно саму логику.

Повторюсь. В правильно спроектированном приложении 80% методов бизнес логики — это pass-through методы. А для оставшихся 20% как раз интересует как оно там правильно легло в базу. Что тогда в бизнес логике тестировать без DAL?

G>Если логики нет и все приложение сводится к изменению записи в БД в ответ на действия пользователя, то тестирование там не нужно. Там нужно что-то типа Dynamic Data.

С этим согласен.

G>ЗЫ В другом проектке с использованием "легковесного DAL" почти вся логика тестируется без БД.

Проекты бывают разные. В некоторых роль БД незначительна. Но, насколько я понял автора топика, это не его случай.

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

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

IT>>>В правильно спроектированном приложении 80% методов бизнес логики — это pass-through методы.
G>>А кто данные получать из базы и передавать в эти методы будет?
IT>Потребитель
А кто в данном случае потребитель?

G>>Как ни крути, а без DAL другие слои будут завязаны на БД, и протестировать их без БД не получится.
IT>Мой вопрос как раз "зачем?" тестировать другие слои без БД если эти слои на 100% завязаны на БД.

IT>>>А для оставшихся 20% как раз интересует как оно там правильно легло в базу.
G>>Наверное всетаки интересует не "как" легло, а "что" легло. Это "что" вполне можно тестировать без БД.

IT>"Что" ты передаёшь в DAL, зачем это тестировать ещё раз? А вот "как" легло? Сработали ли констрейны, тригеры (боже упаси), чего там нагенерировало identity и т.п.
Если большая часть логики сосредоточена в БД (триггеры, констрейнты) и значение identity играет роль, то эту логику тестировать по-другому надо.
В моих проектах большая часть логики сосредоточена в коде и вполне тестируется без базы. БД — только хранилище.

IT>>>Что тогда в бизнес логике тестировать без DAL?
G>>Собственно саму логику.
IT>Повторюсь. В правильно спроектированном приложении 80% методов бизнес логики — это pass-through методы. А для оставшихся 20% как раз интересует как оно там правильно легло в базу. Что тогда в бизнес логике тестировать без DAL?
Тестировать можно много чего, в идеале весь рукописный код. Чем меньше завязок на внешние сервивсы, тем лучше для тестирования.

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

IT>>>>В правильно спроектированном приложении 80% методов бизнес логики — это pass-through методы.
G>>>А кто данные получать из базы и передавать в эти методы будет?
IT>>Потребитель
G>А кто в данном случае потребитель?

В 99% случаев UI.

IT>>"Что" ты передаёшь в DAL, зачем это тестировать ещё раз? А вот "как" легло? Сработали ли констрейны, тригеры (боже упаси), чего там нагенерировало identity и т.п.
G>Если большая часть логики сосредоточена в БД (триггеры, констрейнты) и значение identity играет роль, то эту логику тестировать по-другому надо.

Констрейны — это не логика, это констрейны, декларация. Декларация не тестируется в принципе. Тестируется код на соответсвие этой декларации.

G>В моих проектах большая часть логики сосредоточена в коде и вполне тестируется без базы. БД — только хранилище.

Самое время спросить автора топика какова роль БД в его приложении.

G>Тестировать можно много чего, в идеале весь рукописный код. Чем меньше завязок на внешние сервивсы, тем лучше для тестирования.

Лучше всего для тестирования — это отсутсвие тестирования

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

H>Да, я тоже считаю что Linq2SQL это ORM, все таки любые данные можно вытянуть с помощью одной строки + поддержка связаных сущностей.
Linq2SQL все-таки Relation-Relation Mapping, а не Object-Relation, чем и хорош.

H> Значит вы используйте linq запросы прямо в коде, я все таки тоже склоняюсь к мнению что для линки отдельный слой для доступа к бд является избыточным.
Да вот нет, пожалуй...
Если нет этого слоя, то Бизнес-логика получается гвоздями прибита к БД. А если объект понадобится доставать из других контейнеров — кеш, куки, сессии, веб-сервисы, ect?... Тут вопрос скорее не выделения DAL в отдельный слой, а отделения BL от всех остальных слоев и сервисов.

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

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

IT>>>>>В правильно спроектированном приложении 80% методов бизнес логики — это pass-through методы.
G>>>>А кто данные получать из базы и передавать в эти методы будет?
IT>>>Потребитель
G>>А кто в данном случае потребитель?
IT>В 99% случаев UI.
То есть UI будет завязан на БД. Отличное решение

IT>>>"Что" ты передаёшь в DAL, зачем это тестировать ещё раз? А вот "как" легло? Сработали ли констрейны, тригеры (боже упаси), чего там нагенерировало identity и т.п.
G>>Если большая часть логики сосредоточена в БД (триггеры, констрейнты) и значение identity играет роль, то эту логику тестировать по-другому надо.
IT>Констрейны — это не логика, это констрейны, декларация. Декларация не тестируется в принципе. Тестируется код на соответсвие этой декларации.
То есть констрейнты нельзя протестировать? Могу контр-пример привести.
Насчет деларация или логика — словоблудие. Как не назови, суть одна останется.

G>>Тестировать можно много чего, в идеале весь рукописный код. Чем меньше завязок на внешние сервивсы, тем лучше для тестирования.
IT>Лучше всего для тестирования — это отсутсвие тестирования
Спасибо, поржал.