Где структуры данных принадлежат в приложении WCF?

Question

Скажем, у меня есть веб-проект, который использует службу WCF для скрытой обработки, и проект MVC 2, обрабатывающий веб-запросы (я полагаю, это будет клиент WCF).Служба WCF генерирует данные и обрабатывает предварительно сгенерированные данные (обработка, вероятно, будет происходить асинхронно).Эти две вещи являются отдельными проектами в одном решении в Visual Studio.

Теперь я не уверен, куда поместить структуры данных, представляющие материал, который генерирует сервис, и материал, который клиент должен обработать и отправитьв браузеры пользователей.В настоящее время все они находятся в интерфейсе службы (интерфейс конечной точки? Не уверен, как он называется), помечены [DataContract] (еще не уверен, что это делает).Но, поскольку приложение MVC находится в отдельном проекте, мне придется переопределить все структуры данных там - это необходимо?Должен ли я поместить эти структуры в другом месте в решении?Интерфейс довольно полон определений классов - могу ли я создать какой-то общий ресурс, содержащий общие структуры данных между проектами?Как насчет части [DataContract] - мне все равно нужно что-то добавить в интерфейс, если классы определены где-то еще?

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

Answer 1

Мне нравится структурировать свои решения WCF следующим образом:

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

Реализация службы (библиотека классов)
Содержит код для реализации сервисов и любые вспомогательные / вспомогательные методы, необходимые для достижения этой цели. Ничего другого.

Сервисный хост (ы) (необязательно - может быть Winforms, Консольное приложение, NT Service)
Содержит сервисные хосты для отладки / тестирования или, возможно, также для производства.

Это, в основном, дает мне серверную часть вещей.

На стороне клиента:

Клиентские прокси (библиотека классов)
Мне нравится упаковывать свои клиентские прокси в отдельную библиотеку классов, чтобы их можно было повторно использовать в нескольких реальных клиентских приложениях. Это можно сделать с помощью svcutil или «Добавить ссылку на службу» и вручную настроить получившиеся в результате ужасные файлы app.config или выполнить ручную реализацию клиентских прокси (при совместном использовании сборки контрактов) с использованием конструкций ClientBase<T> или ChannelFactory<T>.

1-n реальных клиентов (любое приложение)
Как правило, будет ссылаться только на сборку прокси-клиентов или сборку контрактов, если она используется совместно. Это могут быть ASP.NET, WPF, Winforms, консольное приложение, другие службы - вы называете это.

Таким образом; У меня хороший и чистый макет, я использую его последовательно снова и снова, и я действительно думаю, что это сделало мой код чище и проще в обслуживании.

Это было вдохновлено фильмом Мигеля Кастро Экстремальный WCF на DotNet Rocks TV с Карлом Франклином - очень рекомендуется снимать экран!

Answer 2

Поместите ваши объекты данных в другой, отдельный проект (выберите Class Library при его создании) и сделайте ссылку на них как из WCF, так и из MVC2 (за исключением дублирования, я не думаю, что будет возможно заставить его работать иначе).

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

Я не уверен, что вы имеете в виду, когда говорите: «Как насчет части [DataContract] - мне все равно нужно что-то добавить в интерфейс» ... Можете ли вы предоставить пример кода?

Для справки, вот код из проекта, над которым я работал в прошлом:

Это в проекте Server.Contracts:

namespace Server.Contracts.DataContracts.Mapped
{
    using System;
    using System.Runtime.Serialization;

    [DataContract]
    public class ConfigSetting : BindableDataContract
    {
        [DataMember]
        public string Name { get; set; }

        [DataMember]
        public string Value { get; set; }

        [DataMember]
        public DateTime ModifiedOn { get; set; }

        public override object Clone()
        {
            return new ConfigSetting
                   {
                       ModifiedOn = this.ModifiedOn,
                       Name = this.Name,
                       Value = this.Value,
                   };
        }
    }
}

Это также в Server.Contracts:

namespace Server.Contracts.ServiceContracts
{
    using System;
    using System.Net.Security;
    using System.ServiceModel;
    using Common.Constants.ServiceModel;
    using Common.LogClient;

    /// <summary>
    /// Interface that defines the log service contract.
    /// </summary>
    [ServiceContract(
    Name = ServiceContract.LogServiceName,
    Namespace = ServiceContract.LogServiceNamespace,
    ProtectionLevel = ProtectionLevel.None, 
    SessionMode = SessionMode.NotAllowed)]
    public interface ILogService
    {
        [OperationContract(Name = "Deferred", IsOneWay = true)]
        void Deferred(LogSeverity severity, DateTime eventTimeUtc, string actor,
                      uint? deviceId, string message, string stackTrace);
    }
}

На этот проект ссылаются эти два других проекта, среди прочих:

• Клиент
• Server.Implementation (где, например, ILogService реализовано)