WCF: Как я должен поддержать классы контракта в клиенте и сервере?
Ваш код немедленно добавит элемент, если первый найденный элемент не имеет того же имени. Вы должны проверить все элементы перед добавлением нового.
$sessions = Session::get('items.item');
$inItems = false;
foreach ($sessions as $session)
if ($request->name == $session['name']) {
$inItems = true;
break;
}
}
if (!$inItems) {
Session::push('items.item',[
'name' => $request->name,
]);
}
4 ответа
Тот подход прекрасен (я использую это вполне немного), как долго, поскольку Вы управляете клиентом. Это не будет работать (очевидно), с клиентами Java и т.д. Если Вы знаете, что никогда не должны будете поддерживать клиенты non-.NET, то это может быть мощно, но это нарушает некоторые пуристские правила SOA. В частности, да, сценарий интранет является тем, где я мог бы рассмотреть этот подход.
И svcutil.exe и IDE имеют опции снова использовать типы от существующих блоков, чтобы сделать точно это.
редактирование, которым состоит в том другое преимущество этого подхода, если Вы хотите использовать ту же логику проверки в клиенте, не кодируя его дважды - например, IDataErrorInfo и т.д.
Если Вашему единственному беспокойству не превращались в наборы массивы, Вы не должны идти настолько далеко. Кнопка Advanced на Добавить Сервисном Ссылочном диалоговом окне позволяет Вам указывать что тип использовать для случаев как это. У Вас может быть он Список использования вместо T [].
Поддержание типов контракта в отдельном, общем блоке является действительно хорошей идеей. Это дает Вам шанс добавить Адаптеры, например, преобразовать между типами контракта и другими бизнес-объектами, которые Вы можете иметь, или Посредники, и т.д., между теми типами.
Имеет смысл использовать общие типы, даже если Вы не управляете всеми клиентами. Предположим, что у Вас есть сервис, который используется внутренними приложениями, которые используют.NET, и также доверенными третьими сторонами в компании партнера. Партнерские приложения используют Java, или Ruby или Python. В этом случае у партнера не будет доступа к общим типам, но доверия разрешению лексической многозначности/XSD, может прокрутить их собственную клиентскую библиотеку типов. Это не должно устранять Вас от обеспечения хорошего пакета общих типов к Вашему внутреннему devs.
Эта рекомендация совместно использовать типы также применяется при использовании интерфейса REST в противоположность WS/SOAP. С REST недостает WSDL, но XSD (или подобный) все еще использовался бы для описания типов сообщений, что сервер и его клиенты обмениваются. Так никакое изменение в советуют независимо от того, используете ли Вы SOAP или REST.
Править: И, это применяется, используете ли Вы.NET или Java или что-либо еще. Если Вы управляете обоими концами провода, и платформы являются тем же, то да, необходимо совместно использовать типы. Почему не был бы Вы?
После того как Вы создали отдельные блоки для содержания контрактов, можно сослаться на эти блоки и использовать их для создания каналов (использующий ChannelFactory) к сервису от клиента. Путем выполнения этого Вы больше не обязаны обновлять 'сервисную ссылку', каждый раз Вы изменяете контракт на обслуживание.
ChannelFactory<IContract> factory =
new ChannelFactory<IContract>("endpointName");