Ado Entity Best Practice

Question

Я просто работаю над этой интересной вещью с объектами ADO.net и нуждаюсь в вашем мнении. Часто было создано решение для предоставления услуги (WCF или веб-службы), чтобы обеспечить доступ к БД через фреймворк сущности, но я работаю над приложением, которое работает внутри, и имеет доступ к домену практически все время. Вопрос в том, является ли хорошей практикой создание службы данных для приложения для интерфейса или я могу перейти от приложения WPF непосредственно к инфраструктуре сущности. Какова наилучшая практика в этом случае, а также некоторые из плюсов и минусов для двух разных подходов.

Answer 1

Используя инфраструктуру сущности напрямую, вы имеете в виду, что приложение WPF будет подключаться к базе данных или что оно все равно будет использовать службы, но повторно использовать объекты?

Если это первый подход, я склонен к этому, потому что это означает, что несколько клиентов подключаются к базе данных, которые: a) являются дополнительной проблемой безопасности, б) могут сделать ее более дорогостоящей с точки зрения лицензирования и c) означает, что вы не получаете преимущества объединения пулов. Базы данных - это самые дорогие вещи для масштабирования, поэтому я бы попытался разработать решение для использования служб и снизить нагрузку на базу данных. Но есть моменты, когда это уместно. Одна вещь, которую я заметил, - это то, что приложения, которые начинают прямое подключение, имеют тенденцию к тому, чтобы получить рефакторинг для перехода через службу позже; это редко бывает наоборот. Но это может быть также случай YAGNI.

Если это второй подход, я думаю, что все в порядке. Обычно люди, смотрящие на WCF, считают «ориентированным на обслуживание» - то есть должен быть строгий договор между службами, и вещи не должны делиться. Но «многоуровневое» приложение, предназначенное только для одного клиента, также является абсолютно правильной архитектурой и не нуждается в такой развязке. В этом случае повторное использование объектов по обе стороны границы обслуживания должно быть прекрасным. Тем не менее, я не уверен, как легко это делать с EF специально, так как я не использовал его, кроме как в экспериментах.

Answer 2

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