Приложение WPF с данными WCF - Службы данных EF, Linq2Sql или WCF - все не так просто

Question

Я делаю что-то, что считаю вполне нормальным (хотя лично мне не приходилось делать это раньше), и я предположил, что будет простой путь вперед, но я еще не нашел его- что действительно расстраивает.

Я буду создавать приложение WPF, которое является бизнес-приложением, ориентированным на данные.Мои данные будут поступать с удаленного сервера IIS (который я контролирую), который имеет стандартную базу данных SQL Server 2008, поэтому Web-сервисы / WCF, похоже, выходят из положения.Удаленный сервис должен быть защищен (разумно) через пользователя (клиента WPF), имя пользователя / пароль.

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

Возможно, я выбрал один из следующих вариантов:

1. ADO.NET Entity Framework через WCF
2. Linq2Sql над WCF
3. Службы данных WCF

При дальнейшем расследовании ни один из вышеперечисленных не кажется «легким делом». Я после

1) ADO.NET Entity Framework - я поиграл с этим и получил всевозможные проблемы, сериализацию объектов через WCF.Даже когда я пытаюсь сгенерировать POCO-сущности и использовать их, мне приходится украшать контракты на обслуживание с помощью пользовательских атрибутов, чтобы все время не допускать ошибок, и мне кажется, что мне нужно провернуть что-то большее, чем простой граф объектов.Мне кажется, что EF просто не предназначен для показа через службу.

2) Linq2Sql - Это не намного лучше, чем EF.Кажется, мне нужно провернуть слишком много вещей.Я пробовал конструктор и SQLMetal, но, похоже, ничто не «просто работает» - все это требует усилий.

3) Службы данных WCF - это кажется хорошим вариантом, но по сути это выглядит какЯ просто выставляю свои таблицы базы данных SQL «в необработанном виде» поверх уровня обслуживания.Я ни в коем случае не являюсь экспертом в этой технологии, но кажется, что это потенциально опасный подход, и вдобавок к этому он не поддерживает какой-либо тип безопасности доступа в качестве стандарта (вам, кажется, придется взломать его, чтобы потребовать аутентификацию).

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

Конечно, это можетхорошо, что «хакерский» обходной путь на EF или Linq2SQL может быть всем, что я могу сделать, и в этом случае я могу засучить рукава и принять тот факт, что я не пропустил более элегантное решение.

Любая помощь / совет будет высоко ценится.

Answer 1

Это немного субъективно, но я предложу мое мнение.

Прежде всего, забудьте о L2SQL - он в основном устарел и не имеет полной поддержки POCO EF4 (это может быть сделано, но требует подстройки XML или генерации SQLMetal), что означает, что сериализация ваших сущностей будет левой. клонирование сущности справа налево.

Я бы пошел с ADO.NET Entity Framework поверх WCF, особенно Entity Framework 4.0. Вы будете иметь большую гибкость в вашей модели (включая способность применять ОО-принципы, такие как наследование).

Использовать Self-Tracking-Entities . Да, вы должны оформить контракты на обслуживание - это сделано специально, и для этого есть много причин.

Вы всегда можете использовать DTO, а не сериализовать действительные сущности EF.

OData действительно хорош в своей гибкости и простоте. Но если вы используете вашу модель только через одно клиентское приложение, специализированный сервисный уровень (WCF) - лучший подход IMO.

Answer 2

3) Службы данных WCF - на первый взгляд это кажется хорошим вариантом, но, по сути, кажется, что я просто выставляю свои таблицы базы данных SQL «в необработанном виде» поверх уровня обслуживания.

Это может быть первое впечатление, но это в корне неверно.В Интернете вы демонстрируете модель - и вы имеете полный контроль над тем, что попадает в эту модель, и как потребители ваших служб данных WCF могут видеть и / или даже обновлять объекты вэта модель.

Вот тут-то и возникает Entity Framework (и там, где Linq-to-SQL терпит неудачу): вы можете захватить вашу базу данных (или, по крайней мере, ее части) в Entity Data Model, а затемизменить это.Вы можете настроить имена ваших сущностей, чтобы они полностью отличались от имен ваших таблиц, вы можете добавить вычисляемые атрибуты, вы можете удалить определенные атрибуты и многое другое.

Если вы говорите о довольно простом приложении, я определенно так и поступлю:

• захватите вашу базу данных и превратите ее в Entity Data Model, используя EF
• предоставляет доступ к EDM через службы данных WCF и определяет, что можно видеть только для чтения, а что можно обновлять по проводам