Блог

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

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

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

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

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

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

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