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

IT>>В 99% случаев UI.
G>То есть UI будет завязан на БД. Отличное решение

Это уж как ты там надизайнишь.

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

Не надо. Тем более что я не утверждал, что констрейнты нельзя тестировать. Так что получится спор с самим собой.

G>Насчет деларация или логика — словоблудие. Как не назови, суть одна останется.

Суть как раз в том, что DAL — это неотемлемая часть бизнес логики и его нужно тестировать точно так же как и всё остальное. А не заниматься ерундой типа тестирования вызовов методов. Это без нас уже Майкрософт потестировал.

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

Мы работаем с Hibernate/NHibernate, но, все сказанное ниже про ADO.NET Entity Framework, актуально и для них. Кроме того, у ORM длинная история: по сути в них сейчас реализованы все шаблоны проектирования уровня DAL, описанные Фаулером, начиная от Repository и заканчивая Active Record; реализован всевозможный дополнительный функционал, к примеру, ленивая загрузка и проксирование, кеширование.

Вопрос #1: Сравнение EF vs LINQ2SQL не полное. Я так и не понял, являются ли одна технология надстройкой над другой, или они дулблируют функционал полностью.

LINQ To SQL и ADO.NET Entity Framework (по крайней мере сейчас) — это две разные технологии. Надстройками друг над другом они не являются. Технологии друг друга не дублируют, потому что LINQ To SQL — это генерирование объектной модели поверх логической модели данных (таблицы, строки, ключи), а ADO.NET Entity Framework — это буквально генерирование объектной модели поверх концептуальной модели данных. Концептуальная модель данных — это модель, которую вы можете смэппировать с логической. Это подробно описано в веб-касте. Т.е. LINQ To SQL — это обертка вокруг логической модели. Есть возможность простого моделирования, но нельзя построить собственную концептуальную модель бизнес-данных, независящую от конкретной базы данных, а затем привязать эту концептуальную модель к той базе данных, которой пока что в природе может не быть.

Сценарии использования:

ADO.NET Entity Framework — это может быть проектирование с концептуальной модели — т.е. вы сначала проектируете концептуальную модель, а затем, используя мэппинг, привязываете концептуальную модель к реальному хранилищу данных в базе данных. При этом концептуальная модель — абстрактная, иными словами, она может достаточно глубоко реализовать принципы ООП, в том числе и такой важный, как наследование. В концептуальной модели (особенность ADO.NET Entity Framework) есть поддержка многоуровневых иерархий наследования.

LINQ To SQL — это технология, к примеру, для создания т.н. "data-driven" приложения, где приложение построено вокруг хранилища данных, и тут нет бизнес-объектов и, скорее всего, нет и бизнес-логики. Т.е. вы идете в проектировании от существующей базы данных.

© Веб-каст по ADO.NET Entity Framework (в замену веб-касту неудачного выступления с Платформы)