Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Засели мы как-то с однокурсником в 2014 году пилить стартап. Срок, результат и направленность продукта для данного текста не важны. Важно то, что клиент был мобильным приложением на Java для Android, а сервер – службой, написанной на C#, общавшейся с хранилищем данных. Далее – поучительная история седым старцам (от программирования) на потеху, безбородым юнцам – в назидание.
Для того, чтобы быть твёрдо уверенным в том, что я, как разработчик серверной части, всё контролирую, первая версия сервера была написана с помощью класса System.Net.Sockets.Socket вроде того, как это описывает статья от Microsoft. Так как сокеты работают (в-принципе, как и все другие перечисленные дальше технологии от Microsoft, кроме WCF) на Begin/End-методах, была написана небольшая обёртка, предоставившая возможность работы с event-based моделью. Это был шаг первый, клиент с сервером прекрасно работали.
Так как весьма скоро нам потребовался SSL, пришлось перейти на уровень модели OSI повыше и переписать серверную часть с использованием класса System.Net.Sockets.TcpListener, к которому и был прикручен SSL. Это были шаги два и два с половиной, клиент с сервером прекрасно работали, клиент даже не пришлось переписывать – перехват пакетов показал, что всё ОК, ничего не изменилось.
Позже захотелось полноценного HTTPS со всеми его наворотами, для чего сервер снова переписали – теперь уже с использованием класса System.Net.HttpListener. Это шаги три и три с половиной, и снова всё хорошо работает, и снова клиент не надо переделывать. Справедливости ради надо заметить, что кроме пользовательского мобильного клиента, существовал ещё и тестовый C#-клиент и куча тестов – а вот их переписывать приходилось почём зря.
Шаг четвёртый пришёл тогда, когда свою систему мы начали масштабировать во всех направлениях, а собственные обёртки стали самым узким местом проекта. Тогда я почитал про WCF и за один вечер (ну почти) переписал всё взаимодействие. Со стороны клиента (и в пересылаемых пакетах) всё осталось по-прежнему, но код серверной части сократился с полудюжины серьёзных классов до считанных строк.
У этой истории две морали.
1. (очевидно) Изобретать велосипеды – это плохо. Если бы я сразу полез в гугл и не побоялся использовать новую для себя технологию, удалось бы сократить разработку сервера примерно на треть.
2. (и это главное) Задача по реализации одного и того же механизма с помощью разных инструментов – наилучший способ обучения, позволяющий добиться глубочайшего понимания темы. Когда ты просто проделываешь что-то несколько раз – ты это запоминаешь. Но когда при этом ты ещё каждый раз усложняешь (изменяешь) используемые инструменты, то навык оттачивается гораздо лучше.
Для того, чтобы быть твёрдо уверенным в том, что я, как разработчик серверной части, всё контролирую, первая версия сервера была написана с помощью класса System.Net.Sockets.Socket вроде того, как это описывает статья от Microsoft. Так как сокеты работают (в-принципе, как и все другие перечисленные дальше технологии от Microsoft, кроме WCF) на Begin/End-методах, была написана небольшая обёртка, предоставившая возможность работы с event-based моделью. Это был шаг первый, клиент с сервером прекрасно работали.
Так как весьма скоро нам потребовался SSL, пришлось перейти на уровень модели OSI повыше и переписать серверную часть с использованием класса System.Net.Sockets.TcpListener, к которому и был прикручен SSL. Это были шаги два и два с половиной, клиент с сервером прекрасно работали, клиент даже не пришлось переписывать – перехват пакетов показал, что всё ОК, ничего не изменилось.
Позже захотелось полноценного HTTPS со всеми его наворотами, для чего сервер снова переписали – теперь уже с использованием класса System.Net.HttpListener. Это шаги три и три с половиной, и снова всё хорошо работает, и снова клиент не надо переделывать. Справедливости ради надо заметить, что кроме пользовательского мобильного клиента, существовал ещё и тестовый C#-клиент и куча тестов – а вот их переписывать приходилось почём зря.
Шаг четвёртый пришёл тогда, когда свою систему мы начали масштабировать во всех направлениях, а собственные обёртки стали самым узким местом проекта. Тогда я почитал про WCF и за один вечер (ну почти) переписал всё взаимодействие. Со стороны клиента (и в пересылаемых пакетах) всё осталось по-прежнему, но код серверной части сократился с полудюжины серьёзных классов до считанных строк.
У этой истории две морали.
1. (очевидно) Изобретать велосипеды – это плохо. Если бы я сразу полез в гугл и не побоялся использовать новую для себя технологию, удалось бы сократить разработку сервера примерно на треть.
2. (и это главное) Задача по реализации одного и того же механизма с помощью разных инструментов – наилучший способ обучения, позволяющий добиться глубочайшего понимания темы. Когда ты просто проделываешь что-то несколько раз – ты это запоминаешь. Но когда при этом ты ещё каждый раз усложняешь (изменяешь) используемые инструменты, то навык оттачивается гораздо лучше.
