[Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.17 09:51
Оценка:
Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".

Вот здесь
Автор: VladD2
Дата: 29.12.17
описаны цели, которые пытались достичь подобным дизайном.

Публикую один из чатов в Скайпе. Думаю, что в такой форме (вопрос, ответ) будет проще объяснить все "за" и "против".

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: Ну надо заметку создать



20.12.17 21:00: Перенесено из 'Nemerle'
20.12.17 21:00: Перенесено из 'Nemerle'
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 30.12.2017 8:43 VladD2 . Предыдущая версия . Еще …
Отредактировано 19.12.2017 9:54 VladD2 . Предыдущая версия .
Отредактировано 19.12.2017 9:54 VladD2 . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.