Architectural considerations for having a portable C++ domain layer interfaced with Java(JNI) and C#(C++/CLI) -
Architectural considerations for having a portable C++ domain layer interfaced with Java(JNI) and C#(C++/CLI) -
i need create desktop app pretty complex , handles particular domain. domain has entities @ end. want ui of desktop app portable different frameworks such java(eclipse rcp plugin) , .net(visual studio plugin).
1.)can write domain layer using c++ , interface java using jni java 2.)use same c++ layer point 1.) interfacing .net (c++/cli) plugin vstudio
what architectural considerations, pitfalls, future issues 1 face if 1 relies on portable c++ layer interfaced higher level apis java , c# rich client desktop application
for illustration 1 of issue face cannot debug , step native code java. there many such items?
should rewrite domain layer using .net , java each type of environment rather keeping portable c++ layer?
why isn't such approach adopted industry? practical issues 1 faces when 1 has jni layer in between view , domain layer?
interfacing domain models in language / on platform really painful , main architectural advice avoid going there.
if want portable desktop app, think improve off writing end-to-end in java (or perhaps jvm language scala or clojure if 1 of people thinks java bit old-fashioned).
rationale:
you'll only need write gui layer once java give access environments need. can run java desktop apps pretty much everywhere has jvm, without recompiling. need take little care avoid hard-coding platform specific features (e.g obvious stuff don't assume "\" file separator, need utilize portablefile/pathseparator
instead). this avoids complexities of having lot of cross-language interfacing. inherently hard problem, since languages have different object format , method calling semantics. java has great open source library ecosystem respect portable code. you can create pretty decent portable uis in java purposes (using swing or swt), , improve in long run developing custom ui layer each target platform. if smart, can architect app gui interacts end domain objects through clean , simple api. if this, easier add together new gui options in future (for illustration web-based front end end). writing app end-to-end in .net feasible , might bit easier on gui side given how microsoft's gui-building tools are, has big disadvantage you're locked windows, portability , platform flexibility goes out of window. in add-on (though depend on domain) think java ecosystem has overall border in terms of library ecosystem , tool back upwards (with things maven).
c# java .net c++-cli jni
Comments
Post a Comment