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.
