I am in the process of moving my existing desktop application to web. The GUI is developed using MFC/VC++ and the buisness logic is written in COM enabled VC++ DLL. This Dll has various responsibilities. Currently this Dll is loaded as part of the desktop application memory.Now I am in the initial stage of moving this application to modern web application. Below is the thought process for design considered till now,
Converting monolithic business logic to micro services.
Deploy the micro services in a server.
My business logic VC++ Com layer can interface with microservices and get data.
Have a API gateway which can communicate to microservices and it can serve to the web client.
In this process I wanted to reuse VC++ Com business logic layer as much as possible. The current com Dll is not supporting multi threading or multi user sessions. This needs to be supported. The next thing would be reusing existing MFC GUI in web.
What are the technologies can be considered to reuse my buisness logic?
For the most code-reuse I think you're on the right track.
You definitely want to separate out the business logic into it's own service and you can expose that via any communication protocol you prefer. The biggest downside to this is that every time functionality needs to be added, it needs to be added in two places, or in this case three: the business logic server, the MFC server, and the web server.
As others have pointed out, MFC was really intended for desktop applications. A "modern web application" is one that is stateless and communicates via message-passing over http(s) with the web browser being the client. There's really no re-using the MFC GUI in the web. The architectures are just too disconnected.
Having said that, and I haven't looked into it too much, but Blazor is a WASM compiler. It has limited support for the .net framework, even less so around the communication portion of it, but it might be able to compile your project. I'd bet against it, however.
I think you'd be better off just focusing on a decent web experience with a SPA and abandoning the MFC/Desktop portion. Maybe later you can circle back and build a GUI through MAUI or WPF that consumes the web API.
Related
I am doing a research on client/server architecture and web applications. I've been reading different thoughts and suggestions around the web. Some saying that web applications are not considered client/server architecture apps while others are saying the exact opposite. I was wondering what is actually the right thing and if someone can provide in depth explanation that would be highly appreciated?
It depends on the architecture/design of your web application(s). The rule of thumb would be: The client application has to be another piece of software than the (resource) server. There is no "one right way" to design a client/server architecture.
The most common implementations for web based applications are MVC (Model View Controller and SPAs (Single Page Applications).
MVC applications (like ASP.NET or ZendFramework) are applications that are booth rendering the client and handling the business logic in the backend and are not based on a client/server model. (An action in a controller handles a request, loads some data and renders an HTML view as the response).
But: If your MVC Application is acting as a proxy calling a "remote" web service internally (via SOAP or whatever), it should be considered a client application.
As an example: A CRM system is running in an intranet network and provides a data-services for desktop clients. You could write a web application that displays data from those services which is then another client application.
The SPA architecture requires the separation of the server from the frontend, the SPA being the frontend, which in turn is the client application. With this requirement you are basically already implementing a client/server architecture. Let's say an AngularJS frontend and the backend could be a REST service (like ASP.NET WebAPI or Lumen).
The choice of where you host the client application does not affect the client/server architecture, since the applications are still separated on execution: the browser executes the JavaScript SPA on the device of the visitor and calls the service in some data center.
Web application is a part of client-server architecture. Any implementations have always two or more tiers, so two or more process communicate each other.
You may take a look on my old presentation "Architecture of enterprise (automated) information system - Layers and levels" that shows different client-server architectures including web application case (the slide "Tiers are physical layers (examples)" shows examples).
My company is big on sharepoint. but server side controls have inherent problem with performance. I want to move page rendering responsibility to client side with concept similar to SPA. what is best framework or architectural style for this.
Single Page Applications are gaining immense popularity these days mainly because of their fluidity and responsiveness. Clearly the framework and architectural style depends heavily upon the requirements.
Framework:-
There are host of frameworks available that can be leveraged depending upon the complexity of the SPA you are planning - Backbone, Angular, Knockout, Ember etc. I personally prefer Angular and Knockout frameworks because of their simplicity and data binding and directive capabilities. Moreover you can also efficiently handle REST calls to SharePoint using Breeze.js. Refer to this link for more details.
Architecture Styles:-
Typically SPAs use MVC or MVVM patterns to decouple the UI aspect from the business logic, but this again is requirement driven. Regardless of the style/pattern it is important to keep the code modular and no to expose implementation details as much as possible.
Packaging:-
As far as SPAs for SharePoint are concerned, the best way to package and deploy them is in the form of SharePoint Hosted Apps. SharePoint Hosted Apps only allow client side code and hence leveraging Javascript object model and REST API for SharePoint making them ideal for deployment of SPA over SharePoint.
References:-
https://www.pluralsight.com/courses/building-sharepoint-apps-spa-angularjs
Can I use node.js server as a web server?
Such as I will run aspx sites or wcf service in node.js server instead
of IIS? Can I do it without IIS?
There are several alternatives to IIS for hosting ASP.NET applications such as:
IIS Express
Apache (Mono)
Cassini (not actively developped)
Kayak Project (not actively developped)
C# WebServer (not actively developped)
Abyss (not actively developped)
There are probably others, but generally most of them aren't actively developed.
Node.js is a little different. It is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. It fetures a event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. It can still act as a web server and serve content. Node applications, to my knowledge, are written in JavaScript.
With this said:
Node.js can run on IIS, that's different from .NET running on Node.js
ASP.NET websites cannot run on Node.js
ASP.NET projects can benefit from using Node.js for some of its operations
ASP.NET has its own technology similar to Node.js and Socket.io called SignalR
TLDR - No, you can't.
These are different technologies, taken from Node.js website:
Node.js® is a platform built on Chrome's JavaScript runtime for easily
building fast, scalable network applications. Node.js uses an
event-driven, non-blocking I/O model that makes it lightweight and
efficient, perfect for data-intensive real-time applications that run
across distributed devices.
It is feasible to develop an aspnx interpreter in javascript, but makes absolutely no sense to implement one programming language in another programming language.
There must be a reason of this question asked, you could instead tell us why do you desire to have Nodejs to become an aspx server, there might be more elegant solution.
I am starting a new project. This will be a Java EE web application. The application will consist of 3 parts, each one having different functionality, but they all belong to one application. I am thinking of using the following architecture:
There will be 4 separate projects (JSF web applications). The first one will be responsible for communication with database and will expose remote EJBs. Let's call the first project "DataLayerProject". The other 3 applications, which I have mentioned above, will consume the EJBs from the "DataLayerProject" in order to communicate with the database. They will represent the presentation layer of the application.
In my opinion this approach will allow to maintain and develop the 3 parts independently of each other. This will make the project more scalable (in case there will be need to add another sub-projects to the main application).
Is this is a viable solution?
Should I use REST services instead of remote EJBs. (Sorry if I am misunderstanding something here)?
There will be the main page from which I will access the other 3 parts. The question is that I need to have single sign on for every application. Thus, by logging in on the main page user is automatically gets logged in the other 3 applications.
Should I use any portal solutions for making the separate web applications work together?
If all your applications are deployed on a single server, then you can use local interfaces for EJBs instead of remote ones and that would be the fastest implementation.
I am currently devising 3 database desktop applications for different users in a manufacturing company (one for the accounting department, sales department, production department). All applications have different functions but they should be able to access the data of the other department to reflect business transactions. What is the best programming language and database to use for this kind project? The three computers are not physically connected so I was thinking of having them to access a remote database. The language I am most familiar with is Java but I am very open to learning others if it would be more beneficial to the company. I was also thinking of having to use Adobe Air as I am adept with web programming but could still run as a desktop app but I can't seem to find sufficient resources of distributed systems using Adobe air. Any ideas would be very much appreciated. Thanks!
Lots of languages will do this just fine, including Java. You're familiar with that so my advice is stick to it with one caveat: depending on your requirements I would seriously suggest examining the possibility of making it a Web app instead. Desktop database apps are somewhat... old-fashioned. More to the point they'll create a bunch of headaches for you such as installation, Swing is annoying and tedious, etc.
As for what database, barring requirements you haven't specified, anything will do so pick something free like MySQL.
So for a desktop Java app I would:
Put the database on a remote server;
Put an application server or Web container on that same server;
Create a Webapp on the app server for handling RPC;
Pick a method of RPC, be it Web services or whatever, and use Spring to implement it;
Create a desktop Java app in Swing and distribute it to clients from the app server via Webstart (JNLP).
If it's a Web app:
Put the database and appserver or Web container on one server;
Pick a Java Web framework and create a bunch of Web pages that do what you want.
In all cases, have it be the same app but just act differently on the user type. This is much better than maintaining three different apps.
Also if you do a Web app, you might want to consider using PHP as it's a fast and proven way of knocking up Web pages and probably sufficient for the kind of internal application that you're doing.