Являются ли DataContracts корпоративного уровня хорошей практикой?

Question

Рекомендуется ли определять DataContracts в сборке уровня предприятия, а затем ссылаться на них в сервисных проектах WCF, а не определять их на уровне решения отдельных сервисов WCF? Все примеры WCF, которые я видел, избегали этой темы и определяли только DataContracts в сервисном решении. Некоторые программисты, с которыми я общаюсь, хотят видеть DataContracts как другой вариант канонической модели данных уровня предприятия вместо локального контракта на обслуживание. Мне еще предстоит найти аргументы за или против этой точки зрения.

Может быть трудно выбрать правильный ответ на этот вопрос, но я постараюсь. По крайней мере, я буду отдавать голоса всему, что, по моему мнению, добавляет мне понимания этой темы.

Answer 1

Мне действительно нравится идея помещать DataContracts (и Service Contracts) в сборки, а затем делиться ими со службами и клиентами и т. Д., Но я не вижу веской причины объединять их в одну монолитную сборку.

Имеет больше смысла помещать их в сборки в зависимости от того, как они используются. Если есть группы из них, которые совместно используются несколькими службами и клиентами, то это одна сборка и т. Д.

Это избавляет от необходимости выставлять метаданные, и я думаю, что это позволит вам делать изящные вещи, такие как подключение к событиям сериализации как на стороне сервера, так и на стороне клиента.

Answer 2

Ребята из IDesign.net рекомендуют делиться сборками контрактов между проектами. Я лично рекомендую это по созданию прокси для всего. Там действительно нет веских причин не к.

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

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

Answer 3

Как и в большинстве вещей в информатике, ответ - это зависит:)

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

Если вы хотите сделать их частью глобальной сборки и используете .NET 3.5 Sp1, знайте, что вам не нужен атрибут DataContract / DataMember для ваших классов данных. Это может быть полезно, если вы не хотите зависеть от System.ServiceModel (а в большинстве случаев нет).