Entity Framework POCO с вопросом разработки программного обеспечения WCF

Question

Я собираюсь использовать Entity Framework и WCF в моем приложении. Предлагаемая практика, как я видел, - это использование POCO с Entity Framework, а также использование классов POCO в качестве DataContracts. Именно для этого и используются POCO и атрибуты, - если я не ошибаюсь.

Однако меня просят использовать отдельные классы для POCO Entity Framework и DataContracts WCF. И использовать отображение между POCO и DataContracts. Например, Foo и FooContract с одинаковыми свойствами.

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

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

Answer 1

Наличие отдельных классов для ваших POCO и ваших контрактов позволит вам создавать службы, ориентированные на сообщения, а не службы стиля RPC.

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

Сервисы, основанные на сообщениях, также в большей степени соответствуют духу сервис-ориентированных архитектур. Вы можете узнать больше об услугах, ориентированных на сообщения, в Wikipedia .

Я бы также предложил взять Сервис-ориентированную архитектуру: концепции, технологии и дизайн от Томаса Эрла, если вас интересуют принципы хорошего дизайна услуг.

Answer 2

Наличие различных классов данных на уровне персистентности и на уровне контрактов обеспечивает максимальную гибкость.Например, вы можете не хотеть выставлять все свои постоянные поля в контракте, или вы можете представлять другую иерархию данных в контракте и т. Д. Это также позволяет изменять оба независимо друг от друга.

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

Answer 3

Я согласен с @JustinNiessner, и лучшее руководство, которое я нашел для разработки приложений .NET с использованием принципов SOLID, - это серия из сообщений от .Net Junkie и связанный с ним проект codeplex .Четко изложено и информативно, стоит прочитать.