Bridging

When you, a Microsoft technology-oriented developer, write software today you have to select the target platforms you would like to support. The platforms are then used to select the tools, technologies, and programming languages you can use for coding the different layers of your application. Below is a non-exhaustive list indicating some possibilities:

  • If you want to build for the Web, you can select ASP .NET MVC/WebApi (with C# code behind for example) or NodeJS (leveraging JavaScript) on the server, and JavaScript/TypeScript (or a framework based on them, like Angular) on the HTML5-enabled browsers.
  • If your app will run on Windows desktop (as a classic app), you can write both your logic and the client using .NET (optionally, with XAML if you use WPF for the user interface), or – why not – C++ (and MFC). Sure, if you’ve already built a Web app using JavaScript you can adapt it to run on desktop with NodeJS, or even inside a Windows app showing the user interface in a WebBrowser/WebView component that loads the JavaScript dynamically.
  • If you think it’s better to prepare for the future and develop for multiple Windows devices you can do it as a Windows Store app on Universal Windows Platform (UWP), using .NET (C#), C++, or JavaScript (the latter, only if you don’t build component libraries). The 7user interface can be designed one time, with slight differences only, for multiple types of screens: desktop-like windows (yeah, now Windows Store apps can run in non-maximized windows), Windows Phones, Surface and other Windows tablets, Xbox One, Surface Hub, and HoloLens (2D easily placed on a wall of your room).
  • If you target more mobile devices, considering that Android and IOS are really everywhere while Windows Phone is virtually nowhere and you cannot simply rely on UWP only (yet), you can choose either Xamarin, leveraging C# (and some XAML) or Apache Cordova tools (to develop a JavaScript-based mobile app) instead, optionally using a framework like Ionic. Note that if you use JavaScript, you can also develop a Web client out of it, and with less effort.
  • Finally, if you want to target the holographic world (HoloLens, Windows Holographic) you can do it the hard way with C++ or C# and DirectX, or – in my opinion – better with Unity (requiring C# or UnityScript with similar syntax to, but not really JavaScript). While for 3D on desktop you could use Unity or DirectX with C# or C++ again, or WebGL and JavaScript.
 

C#

JavaScript

Web server


(ASP .NET + IIS)


(NodeJS)

Browser


(Silverlight)


(HTML5, Angular)

Desktop
(PC)


(WPF, WinForms)


(NodeJS, WebView)

UWP
(PC, Windows Phone, Xbox, Surface Hub, HoloLens)

Mobile
(Android, iOS, UWP)


(Xamarin)


(Cordova, Ionic)

Holographic / 3D
(HoloLens / browser, PC)


(Unity, DirectX)

/ √
(UnityScript / WebGL)

But what if you want to target all the platforms above? Do you have any option? Some of you might say it’s not a common thing among app developers, as usually they would select one of the bullets and stick with that. But I have an easy counterexample: developing user interface components, i.e. software packages to help other developers build their own apps.

For simplicity of the example, let’s say you want to build a fancy 3D chart component and have it available for developers that use all these technologies and frameworks above: WPF (or Windows Forms), UWP (WinRT), HTML5 + JavaScript/TypeScript, AngularASP .NET (WebForms, MVC, WebApi), and Unity. Such components will have some common internal logic (e.g. computing aggregations, such as sums or averages, based on input data) and, regardless of their target platform, their user interface preparation code is, in theory, the same too (e.g. computing the coordinates of the 3D shapes to be presented in the fancy chart doesn’t depend on platforms themselves).

However, you’ll face a technical challenge in order to do what you please with a single code base for the core logic of the component, because the minimum intersection among programming languages required by the selected platforms include both C# and JavaScript (see table above). Some of the platforms support only JavaScript core, and others – like UWP or Unity component development – only .NET/C++, or C#. So you need to duplicate core code that should, otherwise, be the same, making maintenance a mess. (Note that before holograms arrived and 3D development was mostly for games, JavaScript alone was indeed highly cross-platform, but things change!)

Last minute update: Microsoft now offers HoloJS, a C++ based framework to allow JavaScript developers to use WebGL to generate holographic content. While this is bringing JavaScript back as a multi-platform tool that supports most types of app development, it is not enough for component developers who want to deliver native software packages for all types of app developers.

The conceptual solution: keep one programming language (I’d select C#, as it’s easier to maintain) for the core code base, and generate the code in the other language (JavaScript) automatically. Microsoft, however, doesn’t provide any tools for doing this, and they don’t promote any third party to supply a service like this (yet), so you need to search for a solution or develop it yourself.

Any of the two is difficult, but I did some research myself, and I can share the findings: Bridge.net is an open source tool that converts C# to JavaScript with TypeScript definitions in a very nice way! This indeed helps, since having business logic and user interface façade services code written in C# once and then converted automatically to JavaScript allows building native user interface components with more ease, for all selected technologies!

Of course, user interface façade services can be accompanied by other types of ports, such as data access façade services, if you need to also be able to bind the component to external data sources with ease to complete an onion architecture.

diagram

Note that in the diagram above:

  • Data access façade services do not represent a data access layer (DAL); different database technology oriented DALs will be developed, one for each type of data source type that you would like to support; logic from core data access façade services simply offers an interface for DAL to provide data that core logic requires, and to receive data changes when they occur after business logic performs updates (and when such data input/output operations need to be performed, as determined by an app controller which can also be part of the core logic – although separated from domain entities and services).
  • User interface façade services do not represent a user interface layer (UI); different presentation technology oriented UIs will be developed, one for each platform/technology that you would like to support; logic from user interface façade services only prepares data that is required for displaying output properly (e.g. 2D or 3D shape types and coordinates for the fancy chart – yes, you can have multiple instances of UI façade services, one for each type of display, e.g. small or large screen, and 2D or 3D) and receives and adapts input (such as text inputs or pointer events at specific coordinates, converted to actions on the business logic or data access façade services, and controlled by the app logic, again).

Having data access façade services and user interface façade services grouped together with core logic (while still separating them from the middle of the “onion” – the app domain – and also from the app controller) helps you “bridging” more than the business logic of your application or component! (Of course, for each pair of DB and UI platforms you’ll also need a bootstrapper to load the appropriate components – domain logic, app controller logic, user interface façade services, and data access façade services, together with specific DAL and specific UI components.)

I did some tests myself and indeed, the tool works very well, supports many things from C#, including IEnumerable yields and LINQ queries, and therefore I think that Microsoft should promote it together with the beloved Xamarin and Cordova tools. Feel free to vote for it on UserVoice if you agree.

Finally, if you want to also convert your original C# to C++ and Java, due to their high levels of popularity, and build native MVC or JavaFX components too, you can use C#-to-other languages converters, for example from Tangible Software. Note, though, that unlike Bridge.net, these tools are not free and support a smaller subset of C#, e.g. IEnumerable and LINQ queries should be avoided in your core code if you want the conversions to remain fully automatic and keep maintainability a breeze.

Advertisements

About Sorin Dolha

My passion is software development, but I also like physics.
This entry was posted in .NET, Architecture, C#, Development, JavaScript, Unity and tagged , , , , . Bookmark the permalink.

Add a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s