Довольно часто возникает необходимость в создании доп. библиотеки для работы с сторонними сервисами, у которых нет SOAP. К примеру, сервис облачных услуг (хранение данных, вычисления, очереди и пр.), сервис финансовый (список операций, новая операция, разные типы операций) или сервис для получения данных погоды (история погоды, детализация). В этой библиотеке, как правило, нахоидится код авторизации, классы запросов и классы ответов (маппинг данных запросов и ответов), вспомогательный код (преобразования различные и пр.).
Как назвать библиотеку, чтобы другим было сразу понятно ее назначение?
К примеру, у Amazon AWS такая библиотека называется AWSSDK, а в качестве пространсва имен они используют Amazon + тип сервиса (как то EC2). Имхо, название не очень удобное, т.к. SDK -- это набор различных библиотек, документации, утилит, а не сама библиотека. Библиотека -- это часть SDK, а не само SDK.
Можно было бы назвать как AWSApi. Хотя, вроде, тоже не оно, т.к. сама библиотека -- это лишь доп. прослойка для работы с API, а не классы, реализующие API. Или AWSApiClient -- вроде ближе, хотя что такое клиент? Клиент -- это конкретный пользователь, а здесь всего лишь прослойка, часть клиента.
Какое название является наиболее подходящим для такой библиотеки? Что делать, если эта библиотека -- не официальная, т.е. вы как бы не имеете морального права называть ее просто PayPal (т.е. у PayPal может быть своя аналогичная библиотека с их именем)?
Re: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, Shmj, Вы писали:
S>Можно было бы назвать как AWSApi. Хотя, вроде, тоже не оно, т.к. сама библиотека -- это лишь доп. прослойка для работы с API, а не классы, реализующие API. Или AWSApiClient -- вроде ближе, хотя что такое клиент? Клиент -- это конкретный пользователь, а здесь всего лишь прослойка, часть клиента.
Может так: ServicenameInterop? Еще варианты Wrapper/Helper, но это более размыто.
Re: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, Shmj, Вы писали: S>Как назвать библиотеку, чтобы другим было сразу понятно ее назначение?
оп сути это наверное адаптер — вы преобразовываете ненужный вам интерфейс в нужный
S>Какое название является наиболее подходящим для такой библиотеки? Что делать, если эта библиотека -- не официальная, т.е. вы как бы не имеете морального права называть ее просто PayPal (т.е. у PayPal может быть своя аналогичная библиотека с их именем)?
только хелпером пожалуйста не называйте
Re: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, Shmj, Вы писали:
S>Довольно часто возникает необходимость в создании доп. библиотеки для работы с сторонними сервисами, у которых нет SOAP. К примеру, сервис облачных услуг (хранение данных, вычисления, очереди и пр.), сервис финансовый (список операций, новая операция, разные типы операций) или сервис для получения данных погоды (история погоды, детализация). В этой библиотеке, как правило, нахоидится код авторизации, классы запросов и классы ответов (маппинг данных запросов и ответов), вспомогательный код (преобразования различные и пр.).
S>Как назвать библиотеку, чтобы другим было сразу понятно ее назначение?
S>К примеру, у Amazon AWS такая библиотека называется AWSSDK, а в качестве пространсва имен они используют Amazon + тип сервиса (как то EC2). Имхо, название не очень удобное, т.к. SDK -- это набор различных библиотек, документации, утилит, а не сама библиотека. Библиотека -- это часть SDK, а не само SDK.
S>Можно было бы назвать как AWSApi.
Вот не нравится мне такая камелизация. Либо AWSAPI, либо, как я люблю, AwsApi, человекочитаемее.
S> Хотя, вроде, тоже не оно, т.к. сама библиотека -- это лишь доп. прослойка для работы с API, а не классы, реализующие API. Или AWSApiClient -- вроде ближе, хотя что такое клиент? Клиент -- это конкретный пользователь, а здесь всего лишь прослойка, часть клиента.
Client это не пользователь. Это часть пары клиент-сервер, тип взаимодействия участников. Пользователь это User или Customer. Так что AwsClient в принципе подходит (что точнее чем AwsApiClient). Тебе не приходилось разве из серверного кода использовать HttpClient для, например, rest-запросов?
S>Какое название является наиболее подходящим для такой библиотеки? Что делать, если эта библиотека -- не официальная, т.е. вы как бы не имеете морального права называть ее просто PayPal (т.е. у PayPal может быть своя аналогичная библиотека с их именем)?
Connector? Adapter? Facade? Service?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, __kot2, Вы писали:
S>>Как назвать библиотеку, чтобы другим было сразу понятно ее назначение? __>оп сути это наверное адаптер — вы преобразовываете ненужный вам интерфейс в нужный
По-моему Адаптер не подходит. Он обычно пордазумевает, что у тебя есть какой-то "нужный" интерфейс. Т.е. есть некий объект, который понимает только интерфейс А, у нас есть система Б, которую мы хотим использовать. Мы пишем адаптер Б->A, чтобы объект думал, что работает с А, но использовалась Б.
По приведённому топикстартером описанию больше подходит Facade:
* make a software library easier to use, understand and test, since the facade has convenient methods for common tasks;
* make the library more readable, for the same reason;
* reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system;
* wrap a poorly designed collection of APIs with a single well-designed API (as per task needs).
__>только хелпером пожалуйста не называйте
+100500
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, andrey82, Вы писали:
A>>Может так: ServicenameInterop? Еще варианты Wrapper/Helper, но это более размыто.
S>Идея интересная. Но не будет ли запутывать что это стандартное название для COM-оберток?
Interop это сокращение от Interoperability. У меня ассоциация с ситуацией, когда две разные системы полностью друг с другом прозрачно взаимодействуют, обмениваются данными, етс.
В том же COM это означает, что объекты COM в коде .NET выглядят как обычные объекты, и наоборот. Прозрачно преобразуются разные типы данных, вызовы методов, етс.
Ты уверен, что это соответствует твоей ситуации?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, ., Вы писали:
.>Вот не нравится мне такая камелизация. Либо AWSAPI, либо, как я люблю, AwsApi, человекочитаемее.
Но само Api -- немного не к месту.
.>Client это не пользователь. Это часть пары клиент-сервер, тип взаимодействия участников. Пользователь это User или Customer. Так что AwsClient в принципе подходит (что точнее чем AwsApiClient). Тебе не приходилось разве из серверного кода использовать HttpClient для, например, rest-запросов?
Верно. Но эта библиотека не тянет на клиента из пары клиент-сервер. Это лишь часть клиента.
S>>Какое название является наиболее подходящим для такой библиотеки? Что делать, если эта библиотека -- не официальная, т.е. вы как бы не имеете морального права называть ее просто PayPal (т.е. у PayPal может быть своя аналогичная библиотека с их именем)? .>Connector?
А точно будет понятно о чем речь? Что это библиотека для проебразования HTTP-запросов/ответов в объекты запросов/ответов на конкретном языке.
.>Adapter? .>Facade?
Это классика для паттернов, а библиотека не соответствует этим паттернам.
.>Service?
Сервис -- больше подходит для серверной части.
Re[4]: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, ., Вы писали:
.>Interop это сокращение от Interoperability. У меня ассоциация с ситуацией, когда две разные системы полностью друг с другом прозрачно взаимодействуют, обмениваются данными, етс. .>В том же COM это означает, что объекты COM в коде .NET выглядят как обычные объекты, и наоборот. Прозрачно преобразуются разные типы данных, вызовы методов, етс. .>Ты уверен, что это соответствует твоей ситуации?
Ну не то что прозрачно... По сути очень похоже: HTTP-XML-пакеты на одной стороне и объекты данных на другой.
У старика и старухи
Был котеночек черноухий,
Черноухий
И белощекий,
Белобрюхий
И чернобокий.
Стали думать старик со старухой:
— Подрастает наш черноухий.
Мы вскормили его и вспоили,
Только дать ему имя забыли.
Назовем черноухого
"Тучей" —
Пусть он будет большой
И могучий.
Выше дерева,
Больше дома.
Пусть мурлычет он громче грома!
— Нет, — сказала, подумав, старуха, —
Туча легче гусиного пуха.
Гонит ветер огромные тучи,
Собирает их в серые кучи.
Свищет ветер
Протяжно и звонко.
Не назвать ли нам "Ветром"
Котенка?
— Нет, старуха, —
Старик отвечает, —
Ветер только деревья качает,
А стена остается в покое.
Не назвать ли котенка
"Стеною"?
Старику отвечает старуха:
— Ты лишился на старости слуха!
Вот прислушайся вместе со мною:
Слышишь, мышка шуршит за стеною?
Точит дерево мышка-воришка...
Не назвать ли нам кошку — "Мышка"?
— Нет, старуха, —
Старик отвечает, —
Кошка мышку со шкуркой съедает.
Значит, кошка
Сильнее немножко!
Не назвать ли нам кошку кошкой?.
.>>Client это не пользователь. Это часть пары клиент-сервер, тип взаимодействия участников. Пользователь это User или Customer. Так что AwsClient в принципе подходит (что точнее чем AwsApiClient). Тебе не приходилось разве из серверного кода использовать HttpClient для, например, rest-запросов? S>Верно. Но эта библиотека не тянет на клиента из пары клиент-сервер. Это лишь часть клиента.
Вот представь что в твоём клиенте понадобилось скачать файл через фтп. Чем FtpClient будет плох?
S>>>Какое название является наиболее подходящим для такой библиотеки? Что делать, если эта библиотека -- не официальная, т.е. вы как бы не имеете морального права называть ее просто PayPal (т.е. у PayPal может быть своя аналогичная библиотека с их именем)? .>>Connector? S>А точно будет понятно о чем речь? Что это библиотека для проебразования HTTP-запросов/ответов в объекты запросов/ответов на конкретном языке.
Так абстрагируйся от того что именно она там внутре делает. С т.з. интерфейса у тебя будет клиент awsClient.uploadFileToStorate(file).
Т.е. главное обратить внимание на сам интерфейс, что именно он предоставляет, а не то что конкретно он (точнее его некая имплементация) делает внутри. И исходя из этого выбирай имя.
.>>Adapter? .>>Facade? S>Это классика для паттернов, а библиотека не соответствует этим паттернам.
Не знаю. По твоему приведённому описанию соответствует Фасаду. Может ты что-то не договариваешь или я читаю невнимательно.
Имеется в виду, что паттерн — фасад, но это не означает, что слово "Facade" надо делать частью имени классов.
.>>Service? S>Сервис -- больше подходит для серверной части.
Нет, сервис и сервер разные вещи. Ты же сам их назвал сервисами, Сервис погоды, Сервис финансов и т.п. Так и называй WeatherService, FinanceService, что мудровствовать лукаво.
Притом сервис MyCoolService может использовать другие сервисы.
А вообще, если сложно выбрать — подбрось монетку, потом переименуешь, если не понравится.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, ., Вы писали:
S>>Это классика для паттернов, а библиотека не соответствует этим паттернам. .>Не знаю. По твоему приведённому описанию соответствует Фасаду. Может ты что-то не договариваешь или я читаю невнимательно. .>Имеется в виду, что паттерн — фасад, но это не означает, что слово "Facade" надо делать частью имени классов.
Шаблон фасад (англ. Facade) — структурный шаблон проектирования, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.
Фасад -- когда N классов представляем в виде 1.
А у нас на входе HTTP XML-запрос и HTTP XML-ответ (ну, не обязательно XML, может быть POST + XML или JSON + JSON и т.д.) а на выходе класс запроса и класс ответа + вспомогательный код.
.>Нет, сервис и сервер разные вещи. Ты же сам их назвал сервисами, Сервис погоды, Сервис финансов и т.п. Так и называй WeatherService, FinanceService, что мудровствовать лукаво.
Вариант. Собственно, при добавлении SOAP-сервиса в Visual Studio по умолчанию делает пространство имен Service1.
.>А вообще, если сложно выбрать — подбрось монетку, потом переименуешь, если не понравится.
Дык уже не первый год думаю над этим вопросом. Хотелось бы общепринятого -- задача то стандартная.
Вменяемых варианта пока 3 (на примере PayPal):
1. PayPalClient.
2. PayPalService.
3. PayPalApi.
Какой лучше?
Re[5]: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, ., Вы писали: .>По приведённому топикстартером описанию больше подходит Facade: .>
.> * make a software library easier to use, understand and test, since the facade has convenient methods for common tasks;
.> * make the library more readable, for the same reason;
.> * reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system;
.> * wrap a poorly designed collection of APIs with a single well-designed API (as per task needs).
да, возможно.
есть 4 варианта. 3 из википедии. один — от меня
Adapter Converts one interface to another so that it matches what the client is expecting
Decorator Dynamically adds responsibility to the interface by wrapping the original code
Facade Provides a simplified interface
Proxy — ведет себя как другой обьект
Decorator и Proxy это не сюда
остается адаптер и фасад. обычно фасад скрывает сложность системы, множества интерфейсов. когда система запутанная, мы придумываем свои собственные интерфейсы работы с ней и скрываем ее за фасадом. когда понаписали непонятно что, а нам лень разбираться. никогда там не делал, но суть примерно такова
Адаптер — не про систему целиком, а про один конкретный интерфейс
возможно я бы выбрал просто название Service. почему нет? мы хотим сервис — вот и сервис. а что он там делает внутри — нам не интересно. правда, если мы разрабатываем сам код сервиса, тогда у нас получается как бы два сервиса. может путаницу вызвать. Может, действительно, Client тогда?
Здравствуйте, Qulac, Вы писали:
Q>Что мы делаем? Апи к сервису PayPal. Так можно и назвать: PayPalServiceApi.
Апи к сервису PayPal делают разработчики PayPal. Они сделали XML-API к своему сервису, а нам нужно всего лишь использовать их в своем приложении. И мы решили создать отдельную библиотеку, в которой делаем HTTP-запрос к их сервису а возвращаемые данные мапим на объект.
Re[5]: Как назвать библиотеку для взаимодействия со сторонним сервисом?
S>Шаблон фасад (англ. Facade) — структурный шаблон проектирования, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.
S>Фасад -- когда N классов представляем в виде 1.
Заметь, в твоей цитате слово "класс" не встречается... Фасад не требует чтобы это было всё выражено одним единственным классом. Фасадом может быть целый namespace или библиотека.
S>Дык уже не первый год думаю над этим вопросом. Хотелось бы общепринятого -- задача то стандартная.
Дык, все любят иметь своё общепринятое мнение
S>Вменяемых варианта пока 3 (на примере PayPal):
S>1. PayPalClient. S>2. PayPalService. S>3. PayPalApi.
S>Какой лучше?
Я обычно интуитивно выбираю. Сервис это ближе к бизнес-логике. Если ваши бизнес-аналитики|юзеры знают об этом, то будет сервис. Если это твои, программистские заморочки, то клиент. Например, если в требованиях указано как-то передавать файлы, то это будет
FileTransferService, а он будет использовать ScpClient, FtpClient и т.д.
В случае платёжных систем наверное я бы пошел по пути PaymentService использует GoogleWaletClient или PaypalClient.
Имхо, API это более высокоуровневое. API это обычно набор сервисов, типов данных, нотификаций, коллбаков и т.п.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Что мы делаем? Апи к сервису PayPal. Так можно и назвать: PayPalServiceApi.
S>Апи к сервису PayPal делают разработчики PayPal. Они сделали XML-API к своему сервису, а нам нужно всего лишь использовать их в своем приложении. И мы решили создать отдельную библиотеку, в которой делаем HTTP-запрос к их сервису а возвращаемые данные мапим на объект.
Клиентский код будет видеть только ваше апи, и ему все равно сколько под ним еще слоев(апи) находится.
Программа – это мысли спрессованные в код
Re[5]: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, Shmj, Вы писали:
S>Вменяемых варианта пока 3 (на примере PayPal):
S>1. PayPalClient. S>2. PayPalService. S>3. PayPalApi.
S>Какой лучше?
Если речь про дотнет, то всё просто. Выкиньте из головы паттерны и сосредоточьтесь на задаче, которую будет решать сборка.
Обычный принцип: Издатель.Технология.Детали. То же имя будет использоваться как namespace, т.е. встречаться десятки раз по всему коду. Также учитываем, что концепция у вас ещё десять раз поменяется от версии к версии, а имя сборки и типов менять слегка некомильфо. Получаем
using YourApp.PayPal.Payments;
Если в одной библиотеке будут использоваться обёртки для разнотипных сервисов от одной компании — достаточно YourApp.PayPal.
И да,
There are 2 hard problems in computer science: caching, naming, and off-by-1 errors
(с)
Re: Как назвать библиотеку для взаимодействия со сторонним сервисом?
Здравствуйте, Shmj, Вы писали:
S>Как назвать библиотеку, чтобы другим было сразу понятно ее назначение?
Поскольку слово "интерфейс" во всех его смыслах связано с "лицом", пытаемся подобрать жаргонные термины для последнего. Google подсказывает: muzzle, snout.
