Удобство — понятие субьективное. Конкретно с ФБ, произошло так: ВКонтакте скопировал интерфейс, потом ФБ поменял интерфейс, а ВК нет, как оказалось новый интерфейс ФБ, не удобен пользователям ВК :)
Ну а по теме хочу сказать — украл если не все, то 90%. Это очевидно! Даже ваш пост не убедителен. Вы признаете что крадет, а потом оправдываете, какими то своими нововведениями и тем что это нормально. И очень жаль что есть люди, которые считают эту ситуацию нормальной.
Реально надоело, что у нас свои проекты развиваются очень мало, в основном берут западную идею и тупо ее воруют.
А свои, действительно хорошие, проекты просто затеряются в этой массе.
Очень нравится мне Evernote, очень хотел его использовать для хранения как всех заметок и идей, паролей к ремоутам и всего. Но остановило то, что нельза поставить пароль на запуск приложения на Android (и iPad, хотя это менее важно), а так получается телефон потеряешь и все, всю информацию слил.
1. Все дело в том, что WCF создан для решения круга типовых задач. Поэтому всегда будет проигрывать в скорости качественной реализации заточенной под одну конкретную задачу. Плюс WCF в том что все можно сделать проще и с меньшим количеством кода.
2. Ну да, создать классик навесить на него аттрибуты а потом получить готовый клиент через «Add service reference» это конечно ни какого GUI и удобств, а конфигурационные файлики кстати можно править через WCF Service Configuration Editor который есть в студии.
Но неважно как вы создаете сервис через GUI, xml или еще как. Вы пишите на более высоком уровне абстракции, и настоящий код за вас генерят. А сгенерированный код не может быть оптимальным под все задачи, иначе мы бы давно из кирпичиков мышкой весь код собирали.
По этой же причине мой код поверх TCP/IP будет работать быстрее, потому что он заточен под одну конкретную задачу, а не под общий случай.
По поводу приложения, предлагаю вам написать простенькое приложение на WCF, например такой же TimeServer и клиент который запрашивает достаточно много раз время. А затем я перепишу его с использованием сокетов. Замерим и все станет ясно :)
Как вам такой вариант вместо того что бы спорить в теории?
>У WCF нет проблем со скоростью.
У WCF есть проблемы со скоростью, просто потому что WCF написана поверх тех же самых сокетов, и основная ее цель предоставить более простую абстракцию, и чуть ли не все сдалть через GUI. Предлагаю вам написать 2 приложения одно на WCF, а другое на чистых сокетах и посмотреть разницу. В разных сценариях она будет разная, но вряд ли WCF хотя бы в 1м обгонит сокеты.
>Транспорт можно выбрать любой, SOAP и REST...
Можно, но любой из них медленнее чем простой TCP/IP, опять же потому что они реализованы поверх него.
>В БД основная проблема с производительностью это как раз сама БД, а ни как не транспорт
БД бывают разные, если это in-memory key-value storage и вам надо получить из него по списку ключей данных на 100Мб, то передача данных займет в разы больше времени чем их поиск по словарю в памяти БД.
>То есть основная область применения Thrift — если кто-то написал с его помощю серверный код и нужно реализовать клиента?
Это один из сценариев. Другой сценарий, наоборот, если вы хотите не заморачиваясь предоставить доступ из других языков.
А вообще это не альтернатива WCF, я ни в коей мере не агитирую всех бросить WCF, REST и прочее и перейти на Thrift, просто поделилися новой (для меня) технологией, может быть у кого то будет сценарий, когда мой пример пригодится.
В данном примере и клиент и сервер на C# поэтому приемущества не очевидны.
Я отлично знаю как работает WCF. Всякие SOAP'ы, REST'ы и HTTP идут лесом когда вам нужно выжать максимум скорости. Поэтому рано или поздно вы остаетесь со старыми добрыми сокетами. Редко, но так бывает. Это что касается скорости.
А теперь представьте что вы пишете БД, и хотите предоставить как можно больше адаптеров для разных языков программирования, используя Thrift этого можно добится проще. Потому как лично я считаю, что БД претендующая на высокую производительность работающая по HTTP это бред.
Я привел пример того, что например доступ к БД Cassandra можно получить из дотнета именно посредством Thrift, если бы Cassandra была написана по-другому то вряд ли бы мы дотнетчики могли ее пощупать, по крайней мере ждать пришлось бы дольше.
Можно сказать что Thrift изобрели как раз от безысходности, потому что в Facebook используется куча языков и нужно организовать коммуникацию. Но мне кажется это лучше чем сделать это все через HTTP.
Видео хорошее, качественно сделанно, но немного слишком академичное, на мой вкус. Если уж для начинающих, то сначала Hello world а уж потом разбор того как все это работает. Но такого материала ведь и так много, а то о чем вы рассказываете очень хорошо описано у Рихтера, и других.
Лично я бы, лучше написал о advanced tips & tricks, то о чем не все знают и то что выходит за рамки учебников, но может сильно помочь в реальной разработке.
Реально надоело, что у нас свои проекты развиваются очень мало, в основном берут западную идею и тупо ее воруют.
А свои, действительно хорошие, проекты просто затеряются в этой массе.
Здравствуйте, меня зовут %username%
2. Ну да, создать классик навесить на него аттрибуты а потом получить готовый клиент через «Add service reference» это конечно ни какого GUI и удобств, а конфигурационные файлики кстати можно править через WCF Service Configuration Editor который есть в студии.
Но неважно как вы создаете сервис через GUI, xml или еще как. Вы пишите на более высоком уровне абстракции, и настоящий код за вас генерят. А сгенерированный код не может быть оптимальным под все задачи, иначе мы бы давно из кирпичиков мышкой весь код собирали.
По этой же причине мой код поверх TCP/IP будет работать быстрее, потому что он заточен под одну конкретную задачу, а не под общий случай.
По поводу приложения, предлагаю вам написать простенькое приложение на WCF, например такой же TimeServer и клиент который запрашивает достаточно много раз время. А затем я перепишу его с использованием сокетов. Замерим и все станет ясно :)
Как вам такой вариант вместо того что бы спорить в теории?
У WCF есть проблемы со скоростью, просто потому что WCF написана поверх тех же самых сокетов, и основная ее цель предоставить более простую абстракцию, и чуть ли не все сдалть через GUI. Предлагаю вам написать 2 приложения одно на WCF, а другое на чистых сокетах и посмотреть разницу. В разных сценариях она будет разная, но вряд ли WCF хотя бы в 1м обгонит сокеты.
>Транспорт можно выбрать любой, SOAP и REST...
Можно, но любой из них медленнее чем простой TCP/IP, опять же потому что они реализованы поверх него.
>В БД основная проблема с производительностью это как раз сама БД, а ни как не транспорт
БД бывают разные, если это in-memory key-value storage и вам надо получить из него по списку ключей данных на 100Мб, то передача данных займет в разы больше времени чем их поиск по словарю в памяти БД.
>То есть основная область применения Thrift — если кто-то написал с его помощю серверный код и нужно реализовать клиента?
Это один из сценариев. Другой сценарий, наоборот, если вы хотите не заморачиваясь предоставить доступ из других языков.
А вообще это не альтернатива WCF, я ни в коей мере не агитирую всех бросить WCF, REST и прочее и перейти на Thrift, просто поделилися новой (для меня) технологией, может быть у кого то будет сценарий, когда мой пример пригодится.
Я отлично знаю как работает WCF. Всякие SOAP'ы, REST'ы и HTTP идут лесом когда вам нужно выжать максимум скорости. Поэтому рано или поздно вы остаетесь со старыми добрыми сокетами. Редко, но так бывает. Это что касается скорости.
А теперь представьте что вы пишете БД, и хотите предоставить как можно больше адаптеров для разных языков программирования, используя Thrift этого можно добится проще. Потому как лично я считаю, что БД претендующая на высокую производительность работающая по HTTP это бред.
Я привел пример того, что например доступ к БД Cassandra можно получить из дотнета именно посредством Thrift, если бы Cassandra была написана по-другому то вряд ли бы мы дотнетчики могли ее пощупать, по крайней мере ждать пришлось бы дольше.
Можно сказать что Thrift изобрели как раз от безысходности, потому что в Facebook используется куча языков и нужно организовать коммуникацию. Но мне кажется это лучше чем сделать это все через HTTP.
Для сравнения можно написать этот же клиент вручную с использованием сокетов, и сравнить размер и затраченные усилия.
Ну а потом еще портировать его на остальные языки при необходимости, задумываясь о размерах типов данных, big/little endian и прочем.
Лично я бы, лучше написал о advanced tips & tricks, то о чем не все знают и то что выходит за рамки учебников, но может сильно помочь в реальной разработке.