Сообщение [Nitra] Почему клинт-сервер? от 19.12.2017 9:51
Изменено 19.12.2017 9:54 VladD2
Публикую один из чатов в Скайпе. Думаю, что в такой форме (вопрос, ответ) будет проще объяснить все "за" и "против".
Dmitry Golovko: Вариант с сервером какой то тяжеловесный на мой взгляд (он оправдан для работы с 32 битной версией VS) но для отдельного проекта с редактором это по моему перебор.
По идее для интелисенса должна быть отдельная библиотека с публичным апи.
Vlad: Наоборот. Это чистое и незамутненное разделение представления и модели.
Dmitry Golovko: А чем отдельная библиотека этому разделению препятствует?
Vlad: Вот сообщения и есть публичный АПИ.
Dmitry Golovko: Зачем затевать межпроцессорное взаимодействие если есть возможность выполнения в рамках одного процесса?
Vlad: Переверни свой вопрос и попробуй на него ответить.
Vlad: Тут вопрос лучше ставить по другому. Не "зачем", а что дает один и другой подход.
Dmitry Golovko: Дают по идее то же самое
Vlad: Ну, вот не совсем.
Vlad: И потому сейчас почти все движки ИДЕ по этому пути пошли. Райден, Розлин по карайней мере.
Dmitry Golovko: Ну там скорее всего упирается в ограничения по памяти в VS
Vlad: Это только одно "за".
Vlad: Еще — возможность реализации движка IDE для не дотнетной платформы. Месаги то просто плоские данные сериализуемые в поток.
Vlad: Реализуй их передачу на яве или С++ и получишь общение с сервером на дотнете даже не зная про это.
Dmitry Golovko: Это да.
Но для дот нета можно совместить оба подхода и в серверной части добавить открытое апи.
Vlad: Ну, и сама чистота связей. Когда у тебя все в одном процессе невольно хочется использовать какие-то внутренние структуры. А так ты обязан все сериализовать. А значит и сам не захочешь тащить кишки компилятора.
Изменены 12:24:08] Vlad: В итоге АПИ остается простым и легким.
Vlad: На скорость же это никак не влияет, так как все делается довольно крупными транзакциями.
Dmitry Golovko: Для тонких клиентов написанных на дот нете наличие серверной части усложняет интеграцию на мой взгляд
Vlad: Ну, про устойичивость к сбоям и говорить не приходится. Процесс слетит, и отряд не заметит потери бойца...
Dmitry Golovko: АПИ можно оставить один к одному как есть и при работе с библиотекой
Dmitry Golovko: Те де сообщения
Vlad: Ну, где усложняет то? Тебе и так и эдак надо реализовать некий АПИ.
Dmitry Golovko: + добавить запускалку серверной части
Dmitry Golovko: И отслеживать ее работоспособность
Vlad: Если ты пишешь на дотнете, то клиент уже есть. Просто создаешь его экземпляр и пользуешся.
Vlad: Ничем от классического АПИ не отличается.
Vlad: Разве что вместо вызова методов — передаешь сообщения. Но это и в обычном коде бывает. Слышал про модель акторов?
Dmitry Golovko: Да
Vlad: Тут еще один нюанс. Месаги выбраны не просто так. Все АПИ асинхронное. Это нужно чтобы не было тормозов.
Vlad: А с асинхронным, многопоточным кодом крайне неприятно работать теми средствами, что предоставляет тот же Шарп.
Vlad: Вот и была выбрана модель актров, чтобы все взаимодействие был понятным человеку.
Vlad: Пока что эта модель не подводила. Проблем с многопоточностью (тьфу-тьфу) нет.
Dmitry Golovko: Это все понятно — как серверный процесс будет запускаться лучше расскажи?
Vlad: Да молча. Стартует как ехе-шник. Это проблемы клиента.
Vlad: Он создает дочерний процесс и передает ему имена именованных каналов через параметры.
Vlad: Тебе как пользователю АПИ эти детали не важны. Ты просто соззаешь клиент и вызваешь всегда один метод — Send()
Dmitry Golovko: Ну как же не важны
Если я поставляю утилиту редактора то мне важно чтобы как можно проще можно было его установить и запустить без лишних зависимостей
Vlad: Вот отсутствие зависимостей — это еще одно преимущество данного подхода. Твой процесс зависит только от двух длл-ей Nitra.ClientServer.Client.dll и Nitra.ClientServer.Messages.dll.
Dmitry Golovko: Т.е я их подключаю к проекту и дергаю у них метод Send?
Vlad: Все что может прийти с сервера и все что можно послать на сервер описано вообще в одном файле. https://github.com/rsdn/nitra/blob/master/Nitra/ClientServer/Nitra.ClientServer.Messages/Messages.n
Vlad: Т.е я их подключаю к проекту и дергаю у них метод Send?Да
Vlad: Так и работают плагин к Студии и Визуалайзер.
Dmitry Golovko: Ну супер.
Это то что я хотел
При это они создают отдельный процесс?
Vlad: Вот если захочешь на Яве ИДЕ замутить, то придется реализовать обе длл-ки. Но они не так уж сложны.
Vlad: При это они создают отдельный процесс?Да. Точнее создает Nitra.ClientServer.Client.dll
Dmitry Golovko: Ок
Главное что мне этим заниматься не надо
Vlad: Nitra.ClientServer.Messages.dll только содержит месаги и код их сериализации/десериализации (сгенерированный макросами).
Dmitry Golovko: Ок
Главное что мне этим заниматься не надо
Vlad: Ну, каждому главное свое. Кому-то может оказаться приятным, то что можно обращаться к серверу из Явы или С++.
Vlad: И он с радостью реализует эти две Длл-и. Благо они простенькие.
Dmitry Golovko: Это большой плюс
Vlad: Это куча огромных плюсов!
Dmitry Golovko: Согласен
Vlad: Потому и клиент-сервер. Жаль только каждому все это объяснять приходится.
Dmitry Golovko: Ну надо заметку создать
Публикую один из чатов в Скайпе. Думаю, что в такой форме (вопрос, ответ) будет проще объяснить все "за" и "против".
Dmitry Golovko: Вариант с сервером какой то тяжеловесный на мой взгляд (он оправдан для работы с 32 битной версией VS) но для отдельного проекта с редактором это по моему перебор.
По идее для интелисенса должна быть отдельная библиотека с публичным апи.
Vlad: Наоборот. Это чистое и незамутненное разделение представления и модели.
Dmitry Golovko: А чем отдельная библиотека этому разделению препятствует?
Vlad: Вот сообщения и есть публичный АПИ.
Dmitry Golovko: Зачем затевать межпроцессорное взаимодействие если есть возможность выполнения в рамках одного процесса?
Vlad: Переверни свой вопрос и попробуй на него ответить.
Vlad: Тут вопрос лучше ставить по другому. Не "зачем", а что дает один и другой подход.
Dmitry Golovko: Дают по идее то же самое
Vlad: Ну, вот не совсем.
Vlad: И потому сейчас почти все движки ИДЕ по этому пути пошли. Райден, Розлин по карайней мере.
Dmitry Golovko: Ну там скорее всего упирается в ограничения по памяти в VS
Vlad: Это только одно "за".
Vlad: Еще — возможность реализации движка IDE для не дотнетной платформы. Месаги то просто плоские данные сериализуемые в поток.
Vlad: Реализуй их передачу на яве или С++ и получишь общение с сервером на дотнете даже не зная про это.
Dmitry Golovko: Это да.
Но для дот нета можно совместить оба подхода и в серверной части добавить открытое апи.
Vlad: Ну, и сама чистота связей. Когда у тебя все в одном процессе невольно хочется использовать какие-то внутренние структуры. А так ты обязан все сериализовать. А значит и сам не захочешь тащить кишки компилятора.
Изменены 12:24:08] Vlad: В итоге АПИ остается простым и легким.
Vlad: На скорость же это никак не влияет, так как все делается довольно крупными транзакциями.
Dmitry Golovko: Для тонких клиентов написанных на дот нете наличие серверной части усложняет интеграцию на мой взгляд
Vlad: Ну, про устойичивость к сбоям и говорить не приходится. Процесс слетит, и отряд не заметит потери бойца...
Dmitry Golovko: АПИ можно оставить один к одному как есть и при работе с библиотекой
Dmitry Golovko: Те де сообщения
Vlad: Ну, где усложняет то? Тебе и так и эдак надо реализовать некий АПИ.
Dmitry Golovko: + добавить запускалку серверной части
Dmitry Golovko: И отслеживать ее работоспособность
Vlad: Если ты пишешь на дотнете, то клиент уже есть. Просто создаешь его экземпляр и пользуешся.
Vlad: Ничем от классического АПИ не отличается.
Vlad: Разве что вместо вызова методов — передаешь сообщения. Но это и в обычном коде бывает. Слышал про модель акторов?
Dmitry Golovko: Да
Vlad: Тут еще один нюанс. Месаги выбраны не просто так. Все АПИ асинхронное. Это нужно чтобы не было тормозов.
Vlad: А с асинхронным, многопоточным кодом крайне неприятно работать теми средствами, что предоставляет тот же Шарп.
Vlad: Вот и была выбрана модель актров, чтобы все взаимодействие был понятным человеку.
Vlad: Пока что эта модель не подводила. Проблем с многопоточностью (тьфу-тьфу) нет.
Dmitry Golovko: Это все понятно — как серверный процесс будет запускаться лучше расскажи?
Vlad: Да молча. Стартует как ехе-шник. Это проблемы клиента.
Vlad: Он создает дочерний процесс и передает ему имена именованных каналов через параметры.
Vlad: Тебе как пользователю АПИ эти детали не важны. Ты просто соззаешь клиент и вызваешь всегда один метод — Send()
Dmitry Golovko: Ну как же не важны
Если я поставляю утилиту редактора то мне важно чтобы как можно проще можно было его установить и запустить без лишних зависимостей
Vlad: Вот отсутствие зависимостей — это еще одно преимущество данного подхода. Твой процесс зависит только от двух длл-ей Nitra.ClientServer.Client.dll и Nitra.ClientServer.Messages.dll.
Dmitry Golovko: Т.е я их подключаю к проекту и дергаю у них метод Send?
Vlad: Все что может прийти с сервера и все что можно послать на сервер описано вообще в одном файле. https://github.com/rsdn/nitra/blob/master/Nitra/ClientServer/Nitra.ClientServer.Messages/Messages.n
Vlad: Т.е я их подключаю к проекту и дергаю у них метод Send?Да
Vlad: Так и работают плагин к Студии и Визуалайзер.
Dmitry Golovko: Ну супер.
Это то что я хотел
При это они создают отдельный процесс?
Vlad: Вот если захочешь на Яве ИДЕ замутить, то придется реализовать обе длл-ки. Но они не так уж сложны.
Vlad: При это они создают отдельный процесс?Да. Точнее создает Nitra.ClientServer.Client.dll
Dmitry Golovko: Ок
Главное что мне этим заниматься не надо
Vlad: Nitra.ClientServer.Messages.dll только содержит месаги и код их сериализации/десериализации (сгенерированный макросами).
Dmitry Golovko: Ок
Главное что мне этим заниматься не надо
Vlad: Ну, каждому главное свое. Кому-то может оказаться приятным, то что можно обращаться к серверу из Явы или С++.
Vlad: И он с радостью реализует эти две Длл-и. Благо они простенькие.
Dmitry Golovko: Это большой плюс
Vlad: Это куча огромных плюсов!
Dmitry Golovko: Согласен
Vlad: Потому и клиент-сервер. Жаль только каждому все это объяснять приходится.
Dmitry Golovko: Ну надо заметку создать