Anant Chaturvedi

Hi. And I plan to work with Microsoft Technologies and Windows Development. And in my current role as a technical lead in the next upgrade, I'm working with a US-based client in the domain of medical simulation. And what we do here is provide full IT staffing support to the client. We are basically helping them with support. We are helping them with deployments. We are helping them with end-to-end deployments. In the most recent projects that I have worked on, I have more migrated the client's desktop application from.NET Framework 4.6.1 to.NET 8. We have migrated their API from.NET 4.1 to.NET 8. We have worked on migrating their application from this platform to and we have also worked on adding the Azure component to the web application. In my past projects, I have worked with various companies. I've worked with App Center, Microsoft, Microland, Antwerp, and I have worked with various clients in different countries. We have worked in different domains in the banking and financial sector, in logistics and transportation, as well as in Vancouver. Thank you.

In order to migrate, we will have to first understand the structure of the application here. For example, if you have a.NET framework in 4.6 to 4.7, but it is following all the relevant structure, such as the N-tier architecture, then you could be able to use a.NET update assistant to migrate the application as this. However, if it feels like the application is only using the old way of writing code, some analytic application with no business layer, no data access layer, or no conventional sense in that we have in modern practices such as dependency injection, then it is best to restart the application and understand the application from scratch and rewrite the application from scratch. So for example, we worked on migrating the Inbox application from.NET 4.7 to.NET 8. And we realized that this application was written as a traditional way of writing code. They had the forms, they had the code behind it, and they had the API that was integrated directly into the code behind. So we decided, okay, no, we are going to follow a n-tier architecture. And we had it ported. So that way, we were able to segregate different layers, like the data access layer, we segregated the middleware, we added the business layer, and we ensured that the API that was being connected was using the consumer API in the business layer. And the data access layer that was connecting to the database had a separate layer by itself. And we added a logging to it so that we could use the entire exception handling framework of.NET 4. And that way, we were able to keep the code clean. We also added the best practices of dependency injection, so that we could implement design pattern conventions of transient, scope, or singleton, with the stack to how the objects are created or injected in the code.

So, basically, conferencing is when you have multiple users connected to the same application. And the parallelism is when the same process is done on the same text. At least that's how I would interpret it. Conferencing can be solved for different users by maintaining different sessions for different users. And parallelism basically means that we will have to have asynchronous numbers in the API that we are consuming. That way, various processes can go in parallel, and it won't affect any users working in parallel at all.

The best way we have communication between.NET and our application is basically to add an API to the backend. So, what happens is that whenever we have a component in a different end application, and every message that has been added to the front end is sent out as a JSON request to the API. Because the API can handle conferencing, you get real-time responses from the API, and multiple users can log in to the application. It will be able to get various requests from different clients, and I should be able to respond to them in real time.

So the extension methods mostly adhere to the responsibilities to the principles of single responsibility and put and close principle because any extension method that we are writing, it basically performs only a single responsibility. That single code, single logic implementation for the application, and it definitely follows the open close principle because every extension method that we are adding, it has to be open and closed for the same.

The best strategy, I believe, to ensure that the rest API endpoints are both scalable and maintainable is potentially to implement our repository pattern. And in this case, basically, what we do is create repositories for methods, and we segregate different layers for data access and middleware as well as the API endpoints. Points. So what happens is, for example, if I have to extend the endpoints and we have to you won't have to basically change the code at all layers. What we can do is really add a new interface to develop the methods for a new entity or a new feature that we want to add. And we can same way add a different class for a different component into the middleware that is consumed, that will just provide the business logic implementation of the new features. And this will all be happening like asynchronously from the endpoint. So that way, we can have high road scenarios, and still we can have endpoints which are completely scalable.

So, basically, what you have is an event that asks whether or not progress update. And inside the method, we are calling the found progress update is not required to be null. It basically triggers the event from progress update. But nowhere it has been specified where we are going to call this method, public void update progress. The update progress method, that is the one that needs to be added to the delegate, and then the event needs to be triggered.

So, basically, the way I see it, this is a read only test, and it has been initialized in the constructor. And when we are using the variable existing item, it is going to use the first or default method to get the first item of the list that is visible corresponding to the ID of the item that has been passed through the item. But the problem is that the list has not even been initialized at the time of instantiation of this class, and it will have no items at all. And it will have to give a value to the existing item, but it's not going to update anything because the value would be null.

So, be it, a.NET Core application or any application in general, it can be made more secure against SQL injection attacks if we're adding validations to the client side. But I think the most secure way to do that is to ensure that the entire value that's being passed to the backend, basically being used to get the process to be passed. That's where queries in the backend are basically used in SQL stored procedures. That way we can rest assured that whatever values are being passed, they're not getting injected into the frontend. Or even if they are, we can add validation. So it will be like a double validation. We're adding client-side validation, and we can add validation in the stored procedure. So that way, all inquiries that we're using, we won't have to worry about SQL injection attacks.

I'm not sure about this either.

So we can use in C# to basically get the metadata for any class library or any file that we are consuming. And, there are definitely performance considerations because looking at the metadata of any object or any class can affect performance. So I would not use it unless you absolutely have to. So that's why reflection can be really costly if we can take a call on the performance of the application.