Entity Framework / WCF - Безопасный / умный, чтобы отправить entityObjects клиенту Silverlight? - PullRequest
Новая
       30

Entity Framework / WCF - Безопасный / умный, чтобы отправить entityObjects клиенту Silverlight?

2 голосов
/ 14 ноября 2010

Я немного запутался здесь.

У меня есть мои классы POCO, созданные с помощью структуры сущностей, смоделированной из базы данных.

Очевидно, я бы тоже хотел использовать эти классы в клиенте (и любая бухгалтерия по ним была бы полезна, если бы я хотел отправить их обратно и повторно присоединить)

Iпросмотрел классы, сгенерированные для справки службы WCF, и, кажется, немного многословно отправлять их через Интернет, но не похоже, что там есть что-то рискованное с точки зрения безопасности.

И все же я могуне могу найти в интернете ничего подобного.Я иду по совершенно ужасному пути?

Справка?

РЕДАКТИРОВАТЬ: я полагаю, что они технически они не классы POCO, если я сгенерировал их EntityFramework из базы данных;просто чтобы устранить любую возможную путаницу.

1 Ответ

2 голосов
/ 16 ноября 2010

На этот вопрос сложно ответить, не зная более подробной информации о вашей системе, но в конечном итоге вопрос о том, является ли указание ваших сущностей EF в контракте на обслуживание WCF правильным путем или нет, зависит от объема и требований разрабатываемого вами приложения.

Возможно, задайте себе следующие вопросы, которые, мы надеемся, будут определять ваше решение:

  1. Вполне вероятно, что ваша реляционная модель и объектная модель должны будут расходиться? Это может быть обусловлено рядом факторов, но чаще всего требования к отчетности могут приводить к определенному замыслу ваша схема базы данных (для производительности), которую вы не хотите отражать в объектной модели вашего приложения. Использование созданных БД объектов EF на всех уровнях приложения может связать вас с этим дизайном базы данных
  2. Вы обеспокоены тем, что изменения в схеме базы данных могут потребовать от ваших клиентов перегенерировать свои сервисные ссылки? Опять же, использование сущностей EF на всех уровнях вашего приложения означает любые изменения, реализованные в вашем Схема БД (независимо от того, имеет ли это отношение к клиенту или нет) может появиться на интерфейсе службы, что может привести к нарушению совместимости клиента с этим интерфейсом
  3. Является ли производительность проблемой? Как вы упомянули, сгенерированные классы многословны. Вы, вероятно, будете перевозить ненужный багаж через провод, который можно оптимизировать.
  4. Вас беспокоит возможность раскрыть подробности реализации вашей схемы базы данных и механизма сохранения на проводе и вашим клиентам? Учитывая, что вы сгенерировали модель из базы данных, вероятно, быть свойствами, которые предоставляют информацию о вашей схеме и механизме сохранения, которые являются избыточными с точки зрения клиента.

Таким образом, может быть ограниченное количество случаев, когда раскрытие сущностей EF может быть приемлемым, но обычно я хотел бы разработать для изменения и реализовать какой-то шаблон, в котором вы сопоставляете свои сущности EF с легкими "невосприимчивыми" POCO в вашем хранилище слой. EF 4.0 предоставляет возможность кодировать контекст, который возвращает POCO, но в моем текущем проекте мы используем контекст codegen, а затем используем automapper для сопоставления сущностей EF нашим контрактам на данные. За пределами уровня хранилища ничего не известно о сущностях EF, и я чувствую, что это обеспечивает более удобную и надежную конструкцию.

...