Архитектурные соображения относительно наличия переносимого доменного уровня C ++, взаимодействующего с Java (JNI) и C # (C ++ / CLI)

Question

Мне нужно сделать настольное приложение, которое будет довольно сложным и будет обрабатывать определенный домен.Домен имеет сущности в конце.Я хочу, чтобы пользовательский интерфейс этого настольного приложения был переносимым на различные среды, такие как Java (Eclipse RCP Plugin) и .NET (Visual Studio Plugin).Итак,

1.) Я могу написать слой домена с использованием C ++ и интерфейс с Java, используя JNI для Java 2.) использовать тот же уровень C ++, что и в пункте 1.) для взаимодействия с .NET (C ++ / CLI) в качестве плагинадля VStudio

Каковы архитектурные соображения, подводные камни и будущие проблемы, с которыми можно столкнуться, если использовать настольный переносимый слой C ++ с интерфейсами API высокого уровня, такими как Java и C #, для настольного приложения с расширенными возможностями клиента

Например, одна из проблем, с которыми я столкнусь, заключается в том, что я не могу отлаживать и переходить на нативный код из Java.Много ли таких элементов?

Стоит ли просто переписать свой уровень домена, используя .NET и Java для каждого типа среды, а не сохранять его переносимым как слой C ++?

Почему такого не происходит?подход, принятый в отрасли?С какими практическими проблемами можно столкнуться, если у вас есть слой JNI между представлением и уровнем домена?

Answer 1

Взаимодействие с моделями доменов на другом языке / на другой платформе очень болезненно , и мой главный совет по архитектуре - не заходить туда.

Если вам нужно портативное настольное приложение, я думаю, что вам лучше писать его сквозным на Java (или, возможно, на другом языке JVM, таком как Scala или Clojure, если вы один излюди, которые думают, что сама Java немного старомодна).

Обоснование:

• Вам потребуется написать слой GUI только один раз , поскольку Java предоставит вам доступ ко всем необходимым средам.Вы можете запускать настольные Java-приложения практически везде, где есть JVM, без перекомпиляции.Вам просто нужно немного позаботиться о том, чтобы избежать жестких возможностей, характерных для платформы (например, очевидные вещи, такие как «\» в качестве разделителя файлов, вам нужно использовать переносной File/pathSeparator вместо этого).
• Это позволяет избежать сложностей необходимости многоязыкового взаимодействия.По сути, это сложная проблема, поскольку языки имеют различный формат объектов и семантику вызова методов.
• Java обладает великолепной экосистемой библиотек с открытым исходным кодом относительно переносимого кода.
• Для большинства целей вы можете создать довольно приличный переносимый пользовательский интерфейс в Java (используя Swing или SWT), и это, вероятно, лучше в долгосрочной перспективе, чем разработка пользовательского уровня пользовательского интерфейса для каждой целевой платформы.
• Если вы сообразительны, вы можете спроектировать приложение так, чтобы графический интерфейс взаимодействовал с объектами внутреннего домена через чистый и простой API .Если вы сделаете это, то в будущем вам будет проще добавить новые параметры графического интерфейса (например, веб-интерфейс).

Запись сквозного приложения в .Netтакже очевидно выполнимо и даже может быть немного проще в части графического интерфейса, учитывая, насколько хороши инструменты Microsoft для создания графического интерфейса, но имеет большой недостаток в том, что вы теперь эффективно заблокированы в Windows, так что ваша мобильность и гибкость платформы выходят за рамки,Кроме того (хотя это будет зависеть от вашего домена), я думаю, что экосистема Java имеет общее преимущество с точки зрения библиотечной экосистемы и поддержки инструментов (с такими вещами, как Maven).

Answer 2

Если вам нужна модель данных на разных языках, обычным делом является использование DSL для описания модели домена и генерации кода из нее.например, прото буферы.Таким образом, вы можете иметь собственный код C ++, Java, C # и т. Д. Для общей модели предметной области.

---

Одна из ловушек использования библиотеки C ++ из Java - это не похоже на библиотеку Java.Вы должны делать все виды неестественных вещей, чтобы использовать его, и в итоге вы добавляете слой, чтобы сделать его более дружественным к Java.Я думаю, что то же самое для C #

Например, одна из проблем, с которой я столкнусь, заключается в том, что я не могу отлаживать и переходить на нативный код из Java.Много ли таких элементов?

Netbeans поддерживает отладку собственного кода Java +, и вы можете перейти к нативному коду из Java и отладить оба.

Должен ли я просто переписать свой доменслой, использующий .NET и Java для каждого типа среды вместо того, чтобы сохранять его переносимым как слой C ++?

Я бы сказал да, но это я.Для вас может иметь смысл выйти в C ++.Есть плюсы и минусы в обоих направлениях.

Почему такой подход не принят промышленностью?

Разработка на Java и C # (и других языках виртуальных машин) часто рассматривается как более продуктивная и легче найти людей, которые могут ее поддержать.

Каковы практическиевыдает одно лицо, когда между слоем представления и домена находится слой JNI?

Вам необходимо отразить модель домена, поскольку вы не можете просто импортировать ее.т.е. всю модель данных, которую вы предоставляете, необходимо перевести.Это требует создания версий представленной модели на Java, а также кода перевода.(Еще одна веская причина, чтобы все это генерировалось)