WCF Multiple Interface

Question

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

Если кто-то может пролить свет на лучшие практики при разработке моего приложения и реализации службы Duplex WCF с несколькими интерфейсами.

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

Некоторые модели, которые я обнаружил...

Клиент имеет свои собственные классы LINQ to SQL и обрабатывает все данные в и из данных.... ПЛОХО. очень медленно накладные расходы с соединениями LINQ и SQL из-за плохой реализации команды Linq Select.

Другой моделью была разработка сервиса для реализации команд linq to sql, которые используются для операций CRUD, однако это по-прежнему не обеспечивает обновления данных в реальном времени для других клиентов, подключенных к сервису.

Таким образом, я сделал основное приложение, которое, когда клиент входит в сервис там, Канал обратного вызова добавляется в Список обратного вызова. Когда клиент вводит новый контакт в службу, он вызывает обратный вызов всем клиентам канала с новым контактом, а функция на стороне клиента заботится о добавлении контакта в нужное место.

Итак, теперь я хочу реализовать объект User и, возможно, еще 2 других бизнес-объекта, например Project и Item, и скажем Item... моя идея состоит в том, чтобы создать свой сервис следующим образом.

[Serializable]
[DataContract]
[ServiceBehavior(
   ConcurrencyMode = ConcurrencyMode.Single,
   InstanceContextMode = InstanceContextMode.PerCall)]
public class Project: IProject
       {
    [DataMember()]
    public int projectID;
          public int Insert(objSubItem _objSubItem)
    {
        // code here
               }

и т. д.

 [ServiceContract(
    Name = "Project",
    Namespace = "",
    SessionMode = SessionMode.Required,
    CallbackContract = typeof(IProjectCallback))]
public interface IProject
{
    /// <summary>
    /// Inserting a Project record to the database
    /// </summary>
    /// <param name="_project">Project from Client</param>
    /// <return>ProjectID back to the client if -1 then fail</return>
     [OperationContract()]
     int Insert(Project _project);

а также

    public interface IProjectCallback
{
     /// <summary>
    /// Notifies the clients that a Project has been added
    /// </summary>
    /// <param name="_project">Inserted Project</param>
    [OperationContract(IsOneWay = true)]
    void NotifyProjectInserted(Project _project);
}

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

Теперь, если у меня есть несколько объектов, что это лучший способ выложить его.

Я собираюсь создать servce.cs, Iservice.cs и IserviceCallback для согласования клиентского канала. Можно ли также использовать частичные классы службы для реализации Iproject и IUser для правильного вызова обратных вызовов службы, а также для вызова объектов вставить.

я бы сделал это так

 [ServiceContract(Name = "Service",
 Namespace = "", 
 SessionMode = SessionMode.Required, 
 CallbackContract = typeof(IServiceCallBack))]
 [ServiceKnownType(typeof(Project))]
 [ServiceKnownType(typeof(User))]
 public interface IService
 {

     // code here
 }

а также

    [ServiceBehavior(
    ConcurrencyMode = ConcurrencyMode.Single, 
    InstanceContextMode = InstanceContextMode.PerCall)]
    public partial class Service :  IUser
    {

    public int Insert(User _User)
    {
       //       
    }
    }
    public partial class Service : IProject
    {

    public int Insert(Project _project)
    {
       // code here
    }
    }
    public partial class Service : IService
   {

    //   functions here 

    }
    }

если кажется, что подход кажется правильным, если бы он был для одного интерфейса, но чувствую, что мне нужна помощь "Best Practice".

Спасибо заранее,,

Крис Лич

Привет, Ричард, я ценю твой ответ. Как видите, это мой первый и третий пост на форуме, посвященном программированию. Я прожил свою жизнь в программировании очень близко к Google, как показывает моя история автозаполнения Google, но пришло время задавать свои собственные вопросы, поэтому я благодарю вас за вашу помощь. Я действительно хочу понять общий подход к тому, как наилучшим образом управлять согласованностью данных среди распределенных приложений клиент / сервис. Я смотрю на Telerik ORM, а также на Entity Framework как на решение и раскрываю сущности через сервис WCF, но мне не хватает понимания для обеспечения согласованности данных среди клиентов. Мне удалось разработать приложение для чата netDualTcp, и я использовал список контекста обратного вызова клиента для отправки функций соединения / выхода и чата. Мне не хватает общей картины, однако кажется, что если у меня есть версия (статическая) в памяти всех таблиц в моей базе данных sql, и либо клиенты связываются напрямую с этими списками, если это возможно, либо это кажется лучшим для моего пользовательского пользователя элементы управления для обработки соединений, чтобы сервер знал, у кого открыт этот конкретный пользовательский элемент управления, и может направлять изменения тем клиентам, которые зарегистрированы в контракте обратного вызова. Таким образом, клиентам не нужно загружать весь проект каждый раз, когда они хотят открыть приложение. Я имею в виду многоцелевое приложение, такое как прикладная программа "контакт / грант", где пользователи будут использовать разные части приложения и не всегда должны получать доступ ко всей информации одновременно. Когда пользователь впервые входит в систему, я надеюсь, что служба прикрепит контракт обратного вызова для клиента, и несколько битов информации будут загружены обратно клиенту при аутентификации, такой как базовое состояние, т.е. если они администратор, они получают уведомления и т. Д. Один раз. они вошли в систему, они представлены с пустым холстом, но затем начинают загружать пользовательские элементы управления в интерфейс типа стыковочной панели. Я предполагаю, что именно здесь я немного застрял в том, как наилучшим образом управлять параллелизмом и согласованностью, одновременно минимизируя время загрузки / передачи данных клиенту и высвобождая время обработки ЦП на обоих клиентах. Я знаю, что в программировании есть несколько способов сделать это, но я хотел бы узнать от людей на этом форуме, что, по их мнению, лучший подход к этому типу души. Я понимаю, что это глубокая тема, но я чувствую, что зашел так далеко, и была бы признательна за руководство. еще раз спасибо

Answer 1

Обычно я нахожу, что неабстрактный взгляд на услугу приводит меня в нужное место. Что нужно будет сделать потребителям моего сервиса?

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

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

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

Таким образом, сервис проекта должен позволять вам делать все, что связано с проектом или проектами, посредством контракта на обслуживание. Если пользователи могут жить независимо от проектов, то также есть пользовательский сервис. Если они не могут, тогда не имейте пользовательского сервиса, поскольку все должно быть сосредоточено на проекте.

Бизнес-транзакции часто представляют собой нечто большее, чем просто операции CRUD на объектах домена, и сервис должен их моделировать, а не отражать модель данных.