это в основном зависит от сложности, которую вы требуете. Вы используете классы POCO, это хорошая отправная точка. Теперь вам нужно выбрать, какое сложное приложение вы собираетесь создать, какую бизнес-логику вы хотите добавить и что вы хотите показать своим клиентам?
Объект POCO может быть просто DTO, или вы можете превратить объект POCO в бизнес-объект, добавив бизнес-методы и правила непосредственно в этот объект - вы преобразуете объект в шаблон Active record или в объект Domain. Я не вижу причин для сопоставления ваших POCO с другим набором бизнес-объектов.
Представление объекта POCO в сервисе WCF - самый простой способ. Вы можете использовать операции, которые будут работать непосредственно с классом Назначения. Кроме того, вы должны предоставить сервисной информации обо всех классах, полученных из Appointment - отметьте KnownTypeAttribute и ServiceKnownTypeAttribute . Использование сущности часто означает, что сервис вызывает транспортировку больше, чем необходимо - это может быть проблемой для мобильных клиентов с медленным интернет-соединением. Есть один особый момент, о котором вы должны помнить при представлении сущности, которая является корнем агрегации (содержит ссылки на другие права и набор сущностей) - если у вас нет полного контроля над клиентскими приложениями и вы разрешаете клиентам отправлять полностью измененный граф объектов Вы должны проверить не только каждый объект, но и тот клиент, который изменил только то, что ему было разрешено. Пример: предположим, что клиент хочет изменить сущность заказа. Вы отправляете ему Order со всеми сущностями OrderItem, и каждый элемент будет иметь ссылку на свою сущность Product = полный граф объектов. Что произойдет, если вместо модификации Order и OrderItems клиент изменит какой-либо из Продуктов (например, цену)? Если вы не проверите это в своей бизнес-логике, представленной WCF, и передадите измененный граф объектов в контекст EF, это изменит цену в вашей базе данных.
Если вы решите использовать свои сущности как бизнес-объекты, вы обычно не выставляете эти сущности, вместо этого вы создадите большой набор DTO. Каждая операция будет работать с точно определенным DTO для запроса и ответа. Этот DTO будет нести только ту информацию, которая действительно необходима - это сократит полезную нагрузку данных для сервисных вызовов и позволит избежать передачи измененных цен на продукт, потому что вы просто определите свой DTO, чтобы не передавать цену или даже весь продукт от клиента. Это решение требует гораздо больше времени для внедрения и добавляет дополнительный уровень сложности.
Поскольку я упомянул графы объектов, я должен уточнить, что при их использовании существует еще один скрытый уровень сложности: отслеживание изменений. Контекст EF должен знать, что изменилось в графе объектов (по крайней мере, какой OrderItem был изменен, который был добавлен или удален и т. Д.) Для правильного сохранения. Отслеживание и многоуровневое решение является проблемой. Самое простое решение не отслеживает изменения и вместо этого использует дополнительный запрос к EF. Этот запрос возвращает фактическое постоянное состояние графа объекта, и измененный граф объекта объединяется с ним (особое внимание необходимо уделить проверкам параллелизма). Другие решения используют некоторую поддержку отслеживания в сущности - отметьте Отслеживание изменений в POCO и Самообследование сущностей . Но это только для сущностей. Если вы хотите отслеживать изменения в DTO, вы должны внедрить собственное отслеживание изменений. Вы также можете прочитать статьи из журнала MSDN о многоуровневых приложениях и EF:
Антишаблоны, которые следует избегать в приложениях N-уровня ;
Создание приложений N-уровня с EF4