Мы использовали EF для внутреннего проекта среднего размера. Это было n-уровневое приложение с сервером, содержащим бизнес-логику и автономный уровень EF. Клиент был приложением WPF (подключался к серверу через WCF).
В EF есть что-то, что может понравиться, и это может сделать некоторые аспекты вашего DA-слоя очень быстрыми для написания, но я скажу одно: в настоящее время он не очень хорошо поддерживает отключенные приложения. Он работает фантастически, если ваше приложение очень автономно, имеет прямое соединение с базой данных и использует 1 контекст данных, контекст данных управляет вашими объектами данных, извлекает данные и соответствующим образом обновляет базу данных.
Как только вы попытаетесь отключить клиента в любой форме n-уровневой структуры, хотя все становится сложнее. Вы должны либо управлять отключением и повторным подключением своих сущностей из контекстов данных, либо вы должны каким-то образом сериализовать свой контекст данных через клиента. Вы должны использовать несколько контекстов данных (отчасти потому, что наш сервер в любом случае был сервером без сохранения состояния, но также потому, что вы попали в большой беспорядок, пытаясь использовать один контекст данных для нескольких клиентов), и все это становится немного сложнее в управлении. Часть нашего решения состояла в том, чтобы иметь отдельные «бизнес-объекты», которые были созданы из нижнего уровня «ef объекты данных». Затем EF будет управлять этими объектами данных (сохранять их и загружать из базы данных и т. Д.), Но наш собственный уровень BLL будет управлять бизнес-объектами. Для сохранения и загрузки необходим перевод из объектов более высокого уровня в объекты более низкого уровня или наоборот.
В целом все работает хорошо, но в ретроспективе я бы сказал, что EF не полностью готов к серьезному развитию на уровне предприятия. Я слышал, что следующая версия EF в .net 4.0 имеет гораздо лучшую поддержку для отключенных и n-уровневых приложений, но лично я не устал от этого.