Entity Framework со службами RIA, Silverlight - компромисс между развязкой и быстрым развитием

Question

В последнее время я играю с Entity Framework, WCF RIA Services и Silverlight 4. Я впечатлен тем, как быстро вы можете разрабатывать приложения с помощью этих инструментов, и вы получаете много «бесплатно», например пользовательский интерфейс Silverlight автоматически узнает об определенных проверках, которые включены в DataAnnotations в модель EF. Однако в больших приложениях кажется нежелательным, чтобы зависимость от EF распространялась по всему приложению, включая бизнес-логику и пользовательский интерфейс.

Я знаю, что вы можете использовать POCO / IPOCO с Entity Framework, и это, безусловно, вариант для меня. Однако, если вы пойдете по этому пути, вы потеряете некоторые «автоматические» вещи, такие как Silverlight, которые могут показывать проверки моделей без дополнительной работы.

Как люди справляются с этим? Вы отказываетесь от части питания и размещаете интерфейсы между различными уровнями, чтобы отделить другие уровни от EF? Или вы отказываетесь от развязки, чтобы обеспечить более быстрое развитие? Можно ли как-нибудь съесть мой торт и съесть его, чего я не вижу?

Answer 1

Моя группа в настоящее время занимается именно этой проблемой. Мы придумали достойный компромисс, которым все были довольны. Имейте в виду, что, прежде чем все закончится, проекты со временем усложняются, и удобство сопровождения является ключевым. Вы также хотите максимально увеличить повторное использование кода, поэтому замена пользовательского интерфейса (или модульное тестирование) - это минимальное усилие.

Учитывая все это, мы предпочли четко определенный уровень домена вместо того, чтобы продвигать EF вплоть до UI. Это делает модель сердцем приложения и не вынуждает нас соответствовать схеме нашей базы данных. Я знаю, что EF пытается абстрагироваться от своей концептуальной модели, но мы продолжали сталкиваться с небольшими хитростями, которые усложняли использование EF для полного стека. Например, действительно нет подходящего места для применения бизнес-логики с EF. Мы не хотели помещать это в Interceptors, и мы не хотели помещать это в UI. Конечно, для этого может быть разумный обходной путь, но нам не понравилось направление, в которое нас толкали.

Компромисс был в том, чтобы использовать EF, но держать его между хранилищем данных и моделью предметной области. Таким образом, нам по-прежнему не нужно программировать на DataReaders, и мы можем использовать преимущества самостоятельного отслеживания сущностей в домене. Затем мы предоставляем базовые сервисы WCF (не RESTful) из нашего домена нашим интерфейсам.

Для нас дополнительная работа по проверке не имела большого значения. Конечно, наш первоначальный выпуск занимает немного больше времени, но общий цикл обслуживания не занимает много времени, потому что мы не сталкиваемся со сложностями инфраструктуры.