0

I am rewriting an old asp.net 4.0 web forms website that exposes an application's data and logic to the web. I am moving this to a .net core mvc or razor page project. The website has minimal formatting logic and some take-input-and-return-data logic. I am not using his logic because he essentially wrote a procedural, non-OOP version.

I am a little ways into a Razor Pages project right now but am finding myself writing awkward code. My issue is all this data comes from a server socket listener that uses TCP/IP protocol to return xml-like text data.

This is great except the person who wrote the listener (cannot change and have 0 control over it) made it act like a pseudo web api. It is listening on a specific port and ip address. However, It closes the connection after he finishes responding to every request and the only security is relying on the connection coming from specific hosts/servers. So creating an SPA (ideal) is out of the question because I can't connect from the client.

Therefore, all data and model creation has to be done on the server. I could wrap an actual api around the tcp listener but that is for another day. Let's assume this TCP conundrum will not change. How do I best go about this?

I currently am injecting an IDataSource class into the pagemodels. I am then defining "models" that essentially define what data the pagemodel needs those models to have in order to function. I then implement the IDataSource in a class that knows about the tcp connection, call the listener, parse the xml, and return the "model" class as if it was a real repository.

Is there a better way to do this? I am trying to maintain SOC but the data coming back and what is displayed is so interconnected I am almost wondering if I should try another way. I was considering possibly switching to MVC and just have the controller know about the tcp connection and having it call the server, parse the data, and then create a viewmodel and return a view. Or at least injecting those functionalities into the controller while still letting the controller know about the data source.

This would be quicker and make for less awkward proxy classes for the data. Instead, the controller is the application and only shapes the data for different views. Not traditional, but this situation is a bit different.

Any input welcome.

1 Answer 1

1

My first idea would be to write a small proxy for this pseudo web api.

The proxy should be whitelisted so it can contact the listener and it would handle the authentication and authorization of clients that connect from random ip addresses.

Then you can develop your client software using the more established patterns. The biggest difference with a regular web-api would then probably be that you use XML-based data structures in the communication rather than JSON-based data structures.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.