c# - 具有与 Java(JNI) 和 C#(C++/CLI) 接口(interface)的可移植 C++ 域层的架构注意事项

Question

我需要制作一个桌面应用程序，它非常复杂并且可以处理特定的 领域。该域在后端具有实体。我希望这个桌面应用程序的用户界面是可移植的 到不同的框架，如 Java(Eclipse RCP 插件)和 .NET(Visual Studio 插件)。所以

1.)我可以使用 C++ 编写域层并使用 JNI for Java 与 Java 接口(interface)吗 2.) 使用与第 1 点相同的 C++ 层。) 作为 VStudio 的插件与 .NET (C++/CLI) 接口(interface)

架构方面的考虑、陷阱和 future 将面临的问题是什么？ 依赖于一个可移植的 C++ 层，它与更高级别的 API(如 Java 和 C#)接口(interface)，以实现丰富的功能 客户端桌面应用

例如，我将面临的问题之一是我无法从 Java 调试和单步执行 native 代码。 有很多这样的东西吗？

我是否应该针对每种类型的环境使用 .NET 和 Java 重写我的域层，而不是将其保持为 C++ 层的可移植性？

为什么业界不采用这种方法？ 当 View 层和域层之间有一个 JNI 层时，人们面临的实际问题是什么？

Answer 1

用另一种语言/在另一个平台上与域模型交互真的很痛苦，我的主要架构建议是避免去那里。

如果您想要一个可移植的桌面应用程序，我认为您最好用 Java 端到端地编写它(或者如果您是其中一个人，则可能是另一种 JVM 语言，如 Scala 或 Clojure谁会认为 Java 本身有点老套)。

理由:

• 您只需要编写一次 GUI 层，因为 Java 将使您能够访问所需的所有环境。您几乎可以在任何具有 JVM 的地方运行 Java 桌面应用程序，而无需重新编译。您只需要注意避免硬编码特定于平台的功能(例如，不要将“\”假定为文件分隔符，您需要使用可移植的 File/pathSeparator 来代替).
• 这避免了必须进行大量跨语言交互的复杂性。这本质上是一个难题，因为这些语言具有不同的对象格式和方法调用语义。
• Java 在可移植代码方面拥有出色的开源库生态系统。
• 对于大多数用途(使用 Swing 或 SWT)，您可以使用 Java 制作相当不错的可移植用户界面，从长远来看，这可能比为每个目标平台开发自定义用户界面层更好。
• 如果您很聪明，您可以构建应用程序，使 GUI 通过干净简单的 API 与后端域对象进行交互。如果您这样做，那么将来添加新的 GUI 选项会更容易(例如基于 Web 的前端)。

在 .Net 中端到端编写应用程序显然也是可行的，考虑到 Microsoft 的 GUI 构建工具有多好，在 GUI 端甚至可能更容易一些，但有一个很大的缺点，你现在有效锁定在 Windows 中，因此您的可移植性和平台灵 active 将不复存在。此外(尽管这取决于您的领域)我认为 Java 生态系统在库生态系统和工具支持(例如 Maven)方面具有整体优势。