Приветствую.
Не застал вэб программирование как программист. В качестве хобби немного писал WcfService.
Было просто: создал проект-сервис, в клиенте добавил соединение, студия создала всё необходимое, пользуюсь. Изменил апи сервиса — обновил соединение и опять пользуюсь. Вообще не думал об этой части. Ну, только когда аутентификацию делал — покопал немного (нашёл в инете готовое решение )
Решил попробовать Core. Создал клиент WPF на Core. Пытаюсь подключить существующий сервис, и столько ошибок валит, что появляется намек, что технология устарела.
Решил попробовать новомодный WebApi. И сразу "в шоке" Тут вообще всё надо прописывать руками. Роутинги какие-то. Один GetPost создал, второй — уже ambiguous.
Реально всё так плохо?
R3>Приветствую. R3>Не застал вэб программирование как программист. В качестве хобби немного писал WcfService. R3>Было просто: создал проект-сервис, в клиенте добавил соединение, студия создала всё необходимое, пользуюсь. Изменил апи сервиса — обновил соединение и опять пользуюсь. Вообще не думал об этой части. Ну, только когда аутентификацию делал — покопал немного (нашёл в инете готовое решение )
R3>Решил попробовать Core. Создал клиент WPF на Core. Пытаюсь подключить существующий сервис, и столько ошибок валит, что появляется намек, что технология устарела. R3>Решил попробовать новомодный WebApi. И сразу "в шоке" Тут вообще всё надо прописывать руками. Роутинги какие-то. Один GetPost создал, второй — уже ambiguous. R3>Реально всё так плохо?
спеациально для "тебя и меня" создали gRPC: там всё почти всё так, как в WCF, и скорость исполения- в разы более шустрая, чем в Web API
Здравствуйте, takTak, Вы писали:
T>спеациально для "тебя и меня" создали gRPC: там всё почти всё так, как в WCF, и скорость исполения- в разы более шустрая, чем в Web API
Краем глаза посмотрел — там какой-то описательный файл надо создавать. Это то же далеко от WCF.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, takTak, Вы писали:
T>>спеациально для "тебя и меня" создали gRPC: там всё почти всё так, как в WCF, и скорость исполения- в разы более шустрая, чем в Web API
R3>Краем глаза посмотрел — там какой-то описательный файл надо создавать. Это то же далеко от WCF.
По gRPC это еще не до конца реализованная технология.
gRPC для ASP.NET Core сейчас не поддерживается в Службе приложений Azure и служах IIS. Реализация HTTP.sys по протоколу HTTP/2 не поддерживает заголовки в конце HTTP-ответа, которые необходимы gRPC. См. дополнительные сведения на сайте GitHub.
Вызов gRPC через HTTP/2 с Grpc.Net.Client в настоящее время не поддерживается в Xamarin. Мы работаем над улучшением поддержки HTTP/2 в будущих выпусках Xamarin. Grpc.Core и gRPC-Web являются приемлемыми работающими альтернативами, которые доступны на сегодняшний день.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, takTak, Вы писали:
T>>спеациально для "тебя и меня" создали gRPC: там всё почти всё так, как в WCF, и скорость исполения- в разы более шустрая, чем в Web API
R3>Краем глаза посмотрел — там какой-то описательный файл надо создавать. Это то же далеко от WCF.
А в чем сложность файл создать? https://docs.microsoft.com/ru-ru/aspnet/core/grpc/basics?view=aspnetcore-3.1
В совокупности один .proto написать проще, чем классы, service contract, service class. А главное gRPC кроссплатформенный, в отличие от WCF. То есть тот же .proto файл можно использовать для создания клиента на C++ например.
T>>спеациально для "тебя и меня" создали gRPC: там всё почти всё так, как в WCF, и скорость исполения- в разы более шустрая, чем в Web API
R3>Краем глаза посмотрел — там какой-то описательный файл надо создавать. Это то же далеко от WCF.
Здравствуйте, gandjustas, Вы писали:
G>В совокупности один .proto написать проще, чем классы, service contract, service class. ...
В WCF я ничего этого не писал. Может студия писала.
Единственное, что писал — преобразование данных между клиентом и сервером. Хотя в каких-то случаях можно и без этого обойтись.
G>В совокупности один .proto написать проще, чем классы, service contract, service class. А главное gRPC кроссплатформенный, в отличие от WCF. То есть тот же .proto файл можно использовать для создания клиента на C++ например.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>В совокупности один .proto написать проще, чем классы, service contract, service class. А главное gRPC кроссплатформенный, в отличие от WCF. То есть тот же .proto файл можно использовать для создания клиента на C++ например.
S> Ну вообще то WSDL тоже кроссплатформенный.
Да, только WFC это не WSDL, а гораздо шире. Если оставаться в рамках basicHttpBinding, то WFC не особо нужен.
S> Другое дело, что WCF сервер в Коре не будут портировать.
Для коре есть WCF клиент. Который правда только с basic и дружит.
S>Кроме того уже по существующим классам создать прото. Как Wsdl или swagger https://docs.microsoft.com/ru-ru/aspnet/core/tutorials/getting-started-with-nswag?view=aspnetcore-3.1&tabs=visual-studio
swagger\openapi надо отдельно подключать, он по умолчанию не включен. И, несмотря на крутость этой возможности, мало кто использует swagger в своих проектах.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали:
G>>>В совокупности один .proto написать проще, чем классы, service contract, service class. А главное gRPC кроссплатформенный, в отличие от WCF. То есть тот же .proto файл можно использовать для создания клиента на C++ например.
S>> Ну вообще то WSDL тоже кроссплатформенный. G>Да, только WFC это не WSDL, а гораздо шире. Если оставаться в рамках basicHttpBinding, то WFC не особо нужен.
S>> Другое дело, что WCF сервер в Коре не будут портировать. G>Для коре есть WCF клиент. Который правда только с basic и дружит.
S>>Кроме того уже по существующим классам создать прото. Как Wsdl или swagger https://docs.microsoft.com/ru-ru/aspnet/core/tutorials/getting-started-with-nswag?view=aspnetcore-3.1&tabs=visual-studio G>swagger\openapi надо отдельно подключать, он по умолчанию не включен. И, несмотря на крутость этой возможности, мало кто использует swagger в своих проектах.
Поискал .Net Core Soap Service
Нашел
No one has any doubt about the extensibility of Dotnet Core. That’s one of the reasons that right after the launch of Dotnet Core, developers stated moving from .Net to .Net Core, knowing that .Net Core is missing some of the great Features of .Net Framework.
Soap Web Services or WCF was one of that feature that was missing in .Net Core from his earlier release. It was one of the most requested & searched features of .Net Core Framework. So, after 3 months of Dotnet Core release, Mike from Microsoft wrote a blog post about implementing a middleware component for handling SOAP requests & also provided a functional version of the blog’s sample code here: https://github.com/DigDes/SoapCore.
In this article, I’m going to Develop Soap Web Services using .Net Core. A NuGet package is also available for SoapCore. Using this we can take all the advantages of top features such as routing and filters.
T>>>спеациально для "тебя и меня" создали gRPC: там всё почти всё так, как в WCF, и скорость исполения- в разы более шустрая, чем в Web API
R3>>Краем глаза посмотрел — там какой-то описательный файл надо создавать. Это то же далеко от WCF. G>А в чем сложность файл создать? G>https://docs.microsoft.com/ru-ru/aspnet/core/grpc/basics?view=aspnetcore-3.1 G>В совокупности один .proto написать проще, чем классы, service contract, service class. А главное gRPC кроссплатформенный, в отличие от WCF. То есть тот же .proto файл можно использовать для создания клиента на C++ например.
public interface IMyFirstService : IService<IMyFirstService>
{
UnaryResult<string> SumAsync(int x, int y);
Task<UnaryResult<string>> SumLegacyTaskAsync(int x, int y);
Task<ClientStreamingResult<int, string>> ClientStreamingSampleAsync();
Task<ServerStreamingResult<string>> ServertSreamingSampleAsync(int x, int y, int z);
Task<DuplexStreamingResult<int, string>> DuplexStreamingSampleAync();
}
.proto генерится
и солнце б утром не вставало, когда бы не было меня
)
Тут вообще всё надо прописывать руками. Роутинги какие-то. Один GetPost создал, второй — уже ambiguous.
Может студия писала. 