WCF множественный интерфейс - PullRequest
0 голосов
/ 19 июня 2011

Я действительно хочу разобраться с этой технологией 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);
}

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

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

Я подумываю создать 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, или если клиенты связываются напрямую с этими списками, если это возможно, или это кажется лучшим для моего пользовательского пользователя контролирует обработку соединений, чтобы сервер знал о том, у кого открыт этот конкретный пользовательский элемент управления, и может направлять изменения тем клиентам, которые зарегистрированы в контракте обратного вызова. Таким образом, клиентам не нужно загружать весь проект каждый раз, когда они хотят открыть приложение. Я имею в виду многоцелевое приложение, такое как прикладная программа «контакт / грант», где пользователи будут использовать разные части приложения, и им не всегда нужен доступ ко всей информации за один раз. Когда пользователь впервые входит в систему, я надеюсь, что служба присоединит контракт обратного вызова для клиента, и несколько битов информации будут загружены обратно клиенту при аутентификации, такой как базовое состояние, т.е. если они администратор, они получают уведомления и т. Д. Один раз они вошли в систему, они представлены с пустым холстом, но затем начинают загружать пользовательские элементы управления в интерфейс типа стыковочной панели. Я полагаю, что именно здесь я зациклился на том, как лучше всего управлять параллелизмом и согласованностью, одновременно минимизируя время загрузки / передачи данных клиенту и высвобождая время обработки ЦП на обоих клиентах. Я знаю, что в программировании есть несколько способов сделать это, но я хотел бы знать от людей на этом форуме, что они чувствуют, лучший подход к этому типу души. Я понимаю, что это глубокая тема, но я чувствую, что зашел так далеко, и была бы признательна за руководство. Еще раз спасибо

1 Ответ

0 голосов
/ 19 июня 2011

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

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

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

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

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

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

...