Блог

Я создал сложный механизм запросов, для которого я хочу создать фабрику, чтобы помочь людям с общими шаблонами запросов. Все мои методы раскрываются через WCF в виде веб-службы SOAP. Каков наилучший способ убедиться, что моя фабрика проста в использовании для всех клиентов, которые могут захотеть использовать мою службу (поскольку я не ожидаю, что все мои клиенты будут использовать .net)?

Обновление: Я хочу написать несколько заводских методов, чтобы помочь с общими шаблонами для «системы запросов», которую я написал. В настоящее время у меня есть несколько контрактов на операции, доступных в моей Службе, а также несколько контрактов на обработку данных. У меня возникает мысленный блок относительно лучшего способа создать что-то вроде фабрики, чтобы возвращать мои пользовательские объекты запросов для поддержки общих шаблонов, которые, как я предполагаю, они желают.

Конкретным примером этого может быть один метод, возвращающий хиты в мою базу данных на основе объекта поискового запроса, который имеет несколько групп концепций с несколькими совпадениями, мой код переводит все это в деревья выражений LINQ, одной из распространенных групп в этом объекте поискового запроса было бы ограничить результаты только источниками американского происхождения, которые на самом деле представляют собой группу из примерно 20 совпадений и могут меняться, поэтому вместо того, чтобы показывать пример жестко заданного кода, я бы предпочел просто вернуть объект группы на основе данных о том, откуда были получены элементы, которые затем они могут использовать в своем объекте поискового запроса. Это звучит идеально для заводского метода, такого как «GroupFactory.Создайте группу» или что-то другое», но какое для меня лучшее место для этого? Или я просто делаю это намного сложнее в своем уме, чем должно быть?

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

Например, вместо:

 GetMatches(new GetMatchRequest() { 
        Filter = new FilterByState() { 
            "AZ", "CA", "OH", ... }});
 

Считать:

 GetMatches(new GetMatchRequest() { Filter = new FilterByCountry("USA") });
 

Где все общие фильтры являются производными от чего-то подобного FilterBase или реализуются IFilter . На стороне сервера вызовите что-то вроде FilterBase.ConstructQueryObject() , чтобы вернуть более детализированные объекты.