Creating contracts between React front-end and C# back-end? - c#

I consider myself to be pretty well-versed in C#, but with React / Typescript I'm a relative beginner. One thing which I liked about pure C# projects is that my front-end and back-end can both be based off of the same object model, which means when I make an API call to the back-end, I can be sure that the object I'm passing from the front-end corresponds to the object I'm expecting to receive on the back-end.
Does something like this exist with React / Typescript? The project I'm working with, as-written, has an ApiModel.ts file (which is ostensibly auto-generated) that contains the models for the objects I'm passing - but to me, this feels like a weakly-typed setup. Other than a friendly warning message at the top of the file, there is nothing preventing me from modifying the ApiModel.ts file to add properties that are not present on the receiving end (which, presumably, would either cause an error or be handled internally).
Basically - tl;dr, is there any way for me to validate, at compile time, that the API model on the React side properly matches the API model on the C# side?

Related

Build dynamic user interfaces with Blazor and XML

I've been researching ways to build a Web Client using C# that is Single Page and is generated from XML files.
Essentially, I want to have a service that generates XML files that describe the UI of e.g. forms (not the problem). Those XML files are sent to the client, which in term reads the XML and dynamically creates the layout with all the controls. I had hoped to accomplish this in Blazor WebAssembly (I have also looked at ASP.NET WebForms, MVC and CORE (using DevExpress), but none of those are actually meant for SPA clients).
By comparison: We have an Android app that basically does this, similar to what is described right here: https://developer.ibm.com/tutorials/x-andddyntut/
But this time I am not developing an Android app in Java, this is supposed to be a WebClient. And as most coders in the company have a VB.NET background, my head of department would like for it to use C#. But I have tried finding ways to do something like this and have met lots of dead ends, as usually Blazor appears to be used with static pages from design time. I haven't managed to get it to run with RenderFragments, for example.
Any pointers with this would be very much appreciated!
Sincerely,
MR
You can generate the UI dynamycally using RenderTreeBuilder but most of its behavior is intended for internal use (take RenderTreeFrame for example) and therefore I don't think it is a good idea.
In short, I don't believe what you want to achieve is possible.
If these XMLs don't change often, I would think to create a transpiler that converts these XMLs to Blazor code and then recompile the app.
Not a direct answer to creating Forms dynamically, but a suggested alternative method.
For my application I have a number of services which have different properties but are based on underlying common base class. The services defined in several .NET Standard library for each type. The services are things like VoIP, Broadband, FTTC, Ethernet, Router Orders etc. etc. - not much in common, and very different types of data and behaviours.
The base service class has an abstract method called GetView which returns a C# type which is a Razor Component type. Remember in Blazor all those components are just C# classes. The type returned is a Razor Component in the same library (so we have UI as well as business and entity logic encapsulation).
The parent site loads a specific type of service, calls GetView and binds the service to the resulting Component.
That's pretty complicated to describe but I did a proof-of-concept application for this approach in the early days of Blazor as I realised it was going to be capable of this approach: https://github.com/conficient/BlazorDynamicList
There is also a demo site at https://blazordynamiclist.azurewebsites.net/
I won't explain it all in detail here but it follows a similar approach. There is an abstract base class ProductBase that has an abstract method GetViewComponent. Each product can return its preferred Razor Component to display itself.
The 'magic' is the DynamicComponent.cs which is a Razor Component with a BuildRenderTree method that creates a bound instance of the product's component view.

Do I have to really create multiple models?

MS stack developer historically.
I have committed to retooling to the following stack
angular -> ms web.api2 -> C# business objects -> sql server
Being old, I develop the database from requirements and use Codesmith to generate the business logic layer. (yes, I have heard of entity framework. even tried it once).
As I embrace Angular and web API 2
I find that Angular wants me to write a model on the front end. This seems to be just a data structure, I cant even add helper methods to it
So I also often write a class with helper methods that takes an instance of the model. Kind of ugly,but it does marry structure and logic.
I find that Web API2 wants me to write a model. This again seems to be just a data structure. I am exploring the dynamic data type, but really this doesn't buy me much. Instead of writing a class, I'm writing a mapping function.
The question is this:
Is there any way around having 3+ copies of each class spread across the stack?
Codesmith is a very capable code generator... it can gen multiple files... but...
If its just a couple data members, and 3 places, I can copy paste edit and get it done.
Just seems to me that now committing to keeping a data structure in synch in 3 different environments is setting oneself up for a lot of work.
I have spent the last 15 years trying to shove as much code as I can into a framework of inheritable classes so I can keep things DRY.
Am I missing something? Are there any patterns that can be suggested?
[I know this isn't a question tailored for SO, but it is where all the smart people shop. Downvote me if you feel honor bound to do so.]
Not entirely familiar with how CodeSmith generates it's classes, but if they are just plain-old-CLR-objects that serialize nicely, you can have WebApi return them directly to your Angular application. There are purists that will frown upon this, but depending on the application, there may be a justification.
Then, in the world of Angular, you have a few options, again, depending on your requirements/justification, and your application - again, purists will definitely frown upon some of the options.
create classes that match what's coming down from the server (more correct method)
Treat everything as "any", lose type safety, and just access properties as you need them i.e. don't create the model. (obviously less correct method)
find a code generation tool that will explore API end points to determine what they return, and generate your typescript classes for you.
Personally, using Entity Framework, I (manually) create my POCO's for database interraction, have a "view"/DTO class that WebAPI would then send back to the client, and a definition of the object in Typescript, but I am a control freak, and don't like generated code.

Asp.net Web API objects definitions

I am working on the asp.net web api where i have to return back objects in json. With respect to making a better approach and easy for (android/ios)mobile developer to consume these Web APIs and parse json objects, what is best approach for making these objects definitions remain shared amongst webapi project and mobile project, so that if we have to change any property then it can easily be reflected on both projects in a better way. It would be great if someone explains it in detail.
There is no such sync method as you are asking.
On your WebAPI server side you'll define the objects and then return them in your API methods. JSON serialization will be automatically handled by the framework, using your serialization engine of choice (i.e. JSON.NET). Remember that with WebAPI you don't decide the output format server side, you just return a response containing the object(s) and then the framework reads the HTTP HEADERS of the request to determine whether the client asked for JSON or XML and then returns what was asked.
The best thing you can do is define a clear API with nice conventions and keep it documented, and if you change anything have the documentation reflect the changes. Avoid making breaking changes, and if you really must, deprecate a property or an object for at least a couple of versions before removing it.
That's the way all public API work anyway.

How do I validate data in C# based on a Struts validation.xml?

I have a validation.xml file from Struts, and am going to implement a server-side validation in .NET based on it. The validation.xml file is accompanied with a validationMessages.properties file. Are there any .NET libraries which are capable of performing a validation based on a Struts validation file?
In case this has never been done I'll have to either create such a class, since the validation file is too long and complex to be implemented as mere C# logic. Which begs the question: How would I even begin?
The end-goal is to be able to populate a C# class with properties for all fields, execute a validation method with that class as a parameter and have it return a list of validation error messages (or no errors in case of success).
I'd be surprised if anything like that existed; it's relatively unusual to move from Java -> .NET.
First, see if there are any custom validators. That code would need to be duplicated.
Then pick apart the different forms (or actions, depending on how they did validation). Put each of those into a C# class (but see below) rather than one giant one. I'm not sure what you mean by "A C# class with properties for all fields"; personally I'd go more granular.
Or just use an existing C# validation package and do a translator from Apache Commons Validation to the C# configuration (or code).
It should be a relatively straight-forward process since the validation config is well-known and documented, and all the code is available.

JSON based architecture, how best to synchronise front end and back end

Looking at using JSON for a new .net REST based system and it looks great, but there is one thing thats alluding my understanding. What is the strategy for keeping the JSON on either side of the application in sync?
What I mean by that is if you do a GET for : www.mysite.com/item/12345. Then the .net side of the application goes away to the db, retrieves the Item with id 12345 and resolves it to your object model Item that is then serialised to JSON and returned.
If you do a POST to : www.mysite.com/item and pass -
{
"Id": "12346",
"ItemName": "New Item",
"ItemCost": 45
}
Then the .net side of the application picks it up, deserialises it to an Item object and then hands it off to be added to the db.
How do you get both sides, your JS object model and your .net object model serialisation to sync up? Does this just need to be maintained by hand or is there a clever way of providing a template for the JSON based on the serialisation of the .net model?
I'm kinda just looking for best practices and whats the done thing and don't see how the client side knows what JSON to pass to the server side.
Personally I've found it easier to 'drive' these changes for the .NET environment. Not wishing to teach you how to suck eggs but Javascript is a very loosely bound language means changes / functionality / properties can be added on the hoof whereas in .NET it is far easier to test and stablise your POCOs in a more rigid manner.
One method I have recently toyed with is generating empty POCOs from my service when creating objects, manipulating as appropriate before then pushing them back to the service for persistence, etc. It still doesn't resolve that wild-west like feeling of working in Javascript, but at least the DataContracts can match up on a superficial level.

Categories