Лучше публично.

И до сих пор ждем:



Правда это можно и погуглить, но сейчас катастрофически нет времени, так что очень хочется кратки и живой пример.

На юнит-тестирование - очень простое влияние. неPOCO (точнее, отсутствие Persistence Ignorance) требует базы данных для прогонки каждого теста. При этом:
1. Состояние базы должно быть одинаковым для каждого запуска
2. Результат не должен зависеть порядка запуска

Этого довольно трудно достичь, а после достижения - легко поломать. Кроме того, базы данных - не слишком быстрая вещь, когда дело доходит до тестов.
В результате тесты становится трудно писать, они долго выполняются, и девелоперы просто забивают на них.

А в целом на архитектуру - очень размытое понятие. Напиши что-нибудь крупное на EF, узнаешь ;)

Добавлено через 1 минуту и 8 секунд

Посмотри http://blog.wekeroad.com/subsonic/subsonic...mplerepository/

Хм... А разве EF-сущности требуют базу данных для прогонки тестов?   

Ок, простой пример.


Как должен выглядеть CustomerService.CreateCustomer в случае EF? Чтобы он работал во время тестов без базы, а в живой системе - с базой, и честно в нее сохранял без дополнительной пляски с бубном.

Как на счет Mock ?

PashaPash, так уж сложилось, что на данный момент я еще не овладел искусством Unit-тестирования... Видимо, именно поэтому даже после того, как ты привел пример, я не понимаю, в чем разница между POCO/неPOCO в данном случае.

PashaPash, ты как-то заводил разговор о реализации Repository под EF v. 1... Вот блог-пост на эту тему: http://blog.keithpatton.com/2008/05/29/Pol...+Framework.aspx

Idsa, трудность как раз не в том, чтобы реализовать IRepostory, как по ссылке. Трудно реализовать точно такой же IRepository, но уже без EF - т.е. чтобы он корректно сохранял объекты-наследники EntityObject. Попробуй просто набросать код CreateCustomer в примере выше. С использованием репозитория по ссылке, но со второй половиной - работой того же кода без базы данных.

SLeN, Mock - это хорошо, но тоже не слишком тривиально в случае EF. Приведешь пример?

Не, - я от Ef пока отказался в пользу Nhibernate.

p.s.

Меня интересует Object First (DDD) а Ef пока этого не позволяет + я влюбился в рефлекшн оптимизатор Nhibernate =)

Это сообщение отредактировал(а) SLeN - 22.6.2009, 11:45

SLeN, а почему не в пользу родного L2S?

На мой взгляд Nhibernate более зрелая ( большинство проблем с которыми можно столкнутся в реальных проектах - уже столкнулись и решили), за многие годы в нее влилось куча гениальных решений (как я уже говорил один только рефлекшн оптимизатор чего стоит), + у её поведение для меня понятно на интуитивном уровне (тоесть - еслибы я участвовал в разработке некой ORM то использовал бы очень похожие решения).

Я пока с ней только осваиваюсь, но еще не было случая когда бы она меня огорчила =)

SLeN, а что рефлекшн оптимизатор умеет?

Он умеет инжектировать свой код в классы тем самым используя рефлексию только 1 раз при запуске, а после через инжектированый код добираться до приватных членов  - тем самым позволяя бизнес уровню поддерживать инкапсуляцию несмотря на использование ORM.

SLeN, эта куча гениальных решений точно так же влилась в Linq2SQL + добавилась нормальная поддержка Linq.
Linq to SQL тоже использует кодогенерацию "один раз при запуске" и потом заливает данные прямо в приватные члены, без рефлекшена. Просто MS не выпячивал это как супер-рефлекш-оптимайзер. Поработай с L2S немного, он намного интуитивнее остальных ORM.

Все ORM одинаковы - это реализация одного и того же паттерна, отличаются только детали. Насчет зрелости NHibernate - прошел год (!!!) от релиза .net 2.0 до поддержки 2.0, nullable и generics со стороны NHibernate. Полноценной поддержки Linq, на том уровне, на котором она есть в L2S (выборка только использованных в коде полей, лямбды, вылизанная кодогенерация) придется ждать еще года полтора. А в L2S это все появилось уже полтора года назад. Много всяких "рефлекш оптимайзеров и инжектирований кода" в нем уже работает, проверено на куче реальных проектов. NHibernate обречен ползти в хвосте, по довольно очевидным, но независящим от него причинам.

HQL
позволяет


вылизанная кодо генерация тоже присутствует.

лямбд - да не встречалось, но я пока использую версию 1.20 и не смотрел чего в 2.0 запихнули ;)
но и в 1.20 достаточно много стратегий выборки - HQL, QBC, QBE

В общем хочется пока поиграть с этой игрушкой =) , тем более что она очень гибкая и поддерживает кучу стратегий, ну а после того как почувствую себя в ней достаточно уверенно - взглянуть на остальное, к томуже  будет уже с чем сравнивать 

Это сообщение отредактировал(а) SLeN - 23.6.2009, 10:22

Голый SQL тоже позволяет выбирать только определенные свойства. Вся разница в уровне. HQL позволяет это делать в виде строго типизированного кода? что-то вроде


А в Linq 2 SQL - одна - LINQ, и она рвет эти "много" с большим отрывом. За счет преобразования кода C# в SQL запросы.


Сначала нужно смотреть стандартные - встроенные в framework - вещи. А не порты с java, отстающие в развитии на 3 года.