Krutarth Shah

Krutarch Shah. I have more than 12 years of experience. Throughout my experience, I have worked with ASP.NET Technologies. I've been involved with SQL Server database development as well. So initially, I was working as a.NET developer, junior.NET developer. Then I was promoted to senior software developer, and I am also interacting with overseas clients. I'm involved in requirement gathering, converting nontechnical requirements to technical requirements. I'm also involved in technical documentation, defining the architecture of the software. I work with legacy applications as well, which is having the oldest technology. We used to convert that from old technology to new technology based on the customer's request. I'm also involved in people management, apart from the technical part. I'm also getting involved with Azure DevOps. That's one thing. So Azure DevOps, I am working with agile methodologies for managing the project, maintaining the project, getting things done on time, on track, with on-time deliverables. I convert tasks into different modules, into tickets, and then work with them as per the release. So I'm also involved in deliveries and release management. If we talk about the technology stack in-depth, I've worked with ASP.NET technology. I started working with VB.NET and Web Forms. Then I was working with MVC as well as.NET Core. Throughout.NET, I have a good hands-on experience working with it. In one of my recent projects, I was working with.NET Core as well as Web Forms. So altogether, I have a good understanding and knowledge of ASP.NET, SQL Server, databases, and Azure DevOps.

So there are two ways of exception handling in C sharp. So one is global exception handling. That is something we can define in global files, and we can get the logs of it. That is called global exception handling. One common approach is that. That is a common approach we have to follow in any project just to avoid if we do want to disclose the sensitive database information. That is something we can manage. It has a global exception handling. So we can have a custom page for that for some sort of error. So we can display that custom page to the user so they can see, and they'll come back again in case of any unexpected error. So that is one thing. And the other is local exception handling that will be managed by try catch. So try block will have the statements of core or the logic, what we have written. And at the time of execution or the time of build, if we do this kind of approach, if we follow this approach, that will be a best practice, I would say. So the block of statements we provide that needs to be handled in try block, that needs to be developed in try block, and catch statement would be needed to handle the exception. So in case of any exception occurring while runtime, it will be thrown to that catch block, and we can handle that in a different way. We can retry that particular function. We can write the logs. We can maintain the logs. We can get to know the root cause of the error, and we can resolve the issue if it is a certain case to case business issue. So we can resolve it. We can get that thing. There is one more block, which is finally. So finally is something which will execute if the exception is generated or not. So it is not a conditional thing. It is a commendatory thing. It has to be executed. So for an example, if we have written something in try block and the exception is generated, and if we want to execute some sort of code in case of exception handle in case of if exception is thrown or not. So we need to handle that in finally block of statement. So that is something we can do. So there are two ways to be summarized. One is global exception handling, and one is local using try catch and finally statement.

In case of SQL Server with the.NET application, the question is about what would be the steps to ensure the consistency and reliability of data in a distributed.NET application using SQL servers. If we talk about distributed.NET applications, I'll give you an example. So if you are working with an e-commerce application, which has multiple applications, one is the web application, the others are desktop applications, maybe one back-end application for an admin panel, and one for seller applications. So we are managing different sorts of different applications with a single database. A SQL server has the potential to handle multiple.NET applications or maybe multiple different technology stack applications with a single database. And we can have a centralized database across the.NET applications. So what my suggestion or what would be my approach is, like so just to maintain the consistency and reliability of data, we would need real-time data. So real-time data would be the most accurate way to get the things. Because if application 1 is accessing the same data, and at the same time, if application 2 is inserting some data or maybe modifying some data in the same table, then there'll be a conflict. And I'll not say a conflict will lead to an error or a bug, but the user might see the older data, not the modified or not the inserted data. So at the time of request, we have to check whether the data is updated or not. So while clicking on a list, it will show the updated one, not using the cache or the older data or reusing them. So that is my approach. Like, we need to fetch the data on a real-time basis. That is one thing. Secondly, we can do one more thing. Like, we can maintain the data in such a way that if concurrent access to a SQL server has occurred. So at the time, we can use certain locking statements, like the no lock statement; we can use it for selecting the data. Just to avoid the deadlock situation, it will not happen in a smaller application, but on a larger-scale application, we may face this kind of issue where we can see this deadlock situation. Just to avoid it, we can use the no lock statement for that. So these are the steps we need to follow to maintain the consistency and reliability of data in a distributed.NET application using SQL Server.

If we talk about the optimization part, there are a few things we need to follow. Ideally, while defining the structure, we need to make sure that the application should be scalable. So we need to define a structure in such a way with different ops concepts, or maybe we can see solid principles we need to follow just to avoid delays or a bad user experience, or we can say just to improve the performance or to optimize the code. That is one thing. And if we talk about the heavily loaded database, an Azure SQL Server database has a capacity to store a large number of data, maybe more than millions of data we can store in SQL Server. And while fetching the data from SQL Server to the.NET application, it will definitely take some time. So we need to take certain steps to optimize the performance. So what we need to do is, like, we need to have a proper indexing in the select statements. So for the select statement, if we are getting the data from a table, which is having millions of records, we have to follow the indexing of the primary key, which is worst. There will be two types of indexing, cluster and non-cluster. So I would refer to both being implemented as per the need. For example, if we are using a join statement in SQL Server, then we need to have indexing on that particular join or maybe a foreign key, which would be a non-cluster index, and that would be associated with the cluster index or primary key of some other table. So that will create a kind of replica of that particular column in a table. If we talk about memory, then it will be a faster execution. So there will be a separate process running for comparing the data between two tables while doing this join operation. That will be a faster execution, and the data load will be faster. Apart from that, while binding the data to the.NET application, we need to get the real-time data. For example, we are binding a table, which is having millions of records. So we need to use paging for that, and at least we need to show 100 records at a time. And for the next page, we need to fetch the next 100 records. That is one approach I would definitely follow. Secondly, in case of searching the data from SQL Server, so we need to find the data using a keyword search methodology in SQL Server. So like, a query will definitely work, but on a certain column only. I would recommend that. Well, when we don't need to convert the data from Vercare to digital or digital to work, that kind of thing we need to take care.

So, there are multiple approaches for branching strategy in Git. If we are using any Git, it can be Bitbucket. It can be DFS. It can be any. I'll recommend two approaches we need to follow. One would be based on the modules. So if we are working with different releases simultaneously, my approach should be that each and every developer will create tickets for a task. So we will have a master branch for this project, and that will be the main branch of a project. Then we will have a feature branch. The feature branch will be taken out from the master branch itself, and the feature branch will be based on a particular release. So the feature branch will have a description like this: Task number 1, 2, 3, 4, 5, this will be there in a feature branch. Then what we need to do as a developer is we need to create a separate branch for a particular task. From that feature branch, we need to take out a branch and work on that particular branch for completing task 1. And if I'm a developer, I'll take out a branch from feature 1. I'll complete my work. I'll name that branch as task 1. I'll complete my work, and then I'll merge that branch to the feature branch. And then I'll take a branch again from feature for task 2. That will be my approach. I'll delete the task 1 branch if it is not needed. Maybe for future reference, it will be there. But if it is not needed, then we can delete that thing. So if simultaneously, multiple developers are working on multiple features, we can have multiple feature branches, and there'll be lots of task branches we need to work on. And we need to commit back to maybe we can merge the branch to the feature branch. Once the feature is completed, we will be ready for the release. Right? So that feature branch will be merged to the main branch, the master branch, or maybe we can say ideally, we need to manage three different branches for the main branch: production, UAD, and development. The development branch would be for development purposes. UAD would be for QC, and master would be for production. So, accordingly, wherever we want to release things, we will need to merge the branch from that particular feature branch to the main branch, and then we can release the thing. If it is our CICD setup, then it will be auto-deployed. So that is the approach we need to follow. Apart from that, there is one more approach, but that is not related to this particular example. It would be for the developers. So the developer will have their own branch, and they'll work and they'll merge to the main branch, but that would be not relevant for this particular example. That would be therefore a single release option. So for multiple releases, the feature branch strategy would be the most efficient way to work with.

Okay. So in case of Azure DevOps, some improvement of code reviews and the process, how it will work in C# 7 dot net technology. So for example, if we are using Azure DevOps and we are using a Git for particular development, so we are taking the example of previous question only. That would be for the feature branch. So if someone has completed a task and they are merging their raising a pull request, that we can call PR in another word. So they will raise the pull request, and there will be one process. One step will be there for an approval. So approver, they need to select. For example, if I'm a developer and my manager or my team lead is an approver, I need to commit the code, I need to create a pull request to that manager or team lead. And then that manager or team lead will see what lines of code I have changed. If it is relevant, if it can be optimized, or if it is something which will create or have some other impacts on that particular project. So they'll definitely reject the pull request, and they will assign me with the task with some sort of comments. So that will help us to build a quality code. And quality control, I would say, the quality control will be also done at the same time. So I'll do the necessary change. I'll raise the pull request again, and then the manager will check, okay, these things are fine. Then it will be merged to the feature branch or the main branch, whatever it is needed. So these are the strategies to improve the code review process. If we talk about Azure DevOps, so Azure DevOps are providing a feature of agile methodology. So agile methodology will be a part of when they are having certain steps. Step number 1 would be requirement gathering, and then we do the analysis part, and we define the models and tickets or stories. Even we can work with the epics. So that will be done, and then we will be working on the development piece. So once the development is done, as an agile methodology, or if we talk about Azure DevOps feature, we need to do the merge process. I mean, once we complete the code, we need to create a PR. That would be there. If it will be accepted by the manager or team lead, then it will be approved, and then it will go for the next step for QC. If it is not, then it will go again to the developer. So it will be a kind of circular thing until the things will be executed in a proper manner. And there will be one exit point where the code is merged or the code is done in a proper manner. And unless it will be there in a loop itself. And the manager or team lead will define when where to exit. So if they will give a green signal and they'll merge the code, then we need to move for the next step. So that is the strategy, and that is the process to improve the code review.

So we have class 1. The class name is order. We have one method, which is return type is decimal. Calculate total discount. And we have two input parameters. One is list of products, and the other is customer. Okay. So it's an object from customer. One is list. Ideally, it should be, the list of something. For example, list of products. Right? So that is one issue there. So list should be, it should be written as list of then products. So list<products, product. There is one class defined below that, and then the closing angle bracket should be there, and then the products would be there. So I'm just reviewing the code again, for our next steps. So decimal discount is equal to 0m. That is some sort of fine. If customer.easepremium is okay. This is the Boolean parameter. Okay. Anyways, if that is true, then, okay, the loop will be there. Product in products. So they are running a for each loop for products list. Discount will be added products.price into 0.1m. Okay. So the discount will be added by 10%. Yeah. And they will return the discount. So, ideally, I don't see any other issue in this block of code. Right? So the main issue I will see is in the input parameters of calculate total discount. That is list of product. It should be list of products. Right. So that is one issue I can see. Apart from that, the code is fine.

Again, SQL statement, we're trying to we try all unique parameters of unique pairs of customers who have ordered the same product. Okay. However, there is a stable flaw present. Can you spot it and explain how it would impact the result? More how we how would you rectify the SQL query while maintaining the intended purpose. Okay. So this is the SQL statement we have. I'll just go through with it. so select testing, customer ID, customer ID. Okay. So we are getting it from 2 different tables. Okay. Order 1 and order 2 on. Okay. Product ID, they are having a join on it. Then customer 1. Okay. Order 1 dot customer ID is gonna be 2. Customer 1 dot customerid. Customer 2, that is also fine. The customer 1 dot customerid is not equal to. Okay. So if the customers are not matching and they are having a set of, customer IDs with 2 different, orders. So that is their approach, and they want a pair of it. So now we are trying to get the key pair kind of thing. we are trying to get a pair unique pairs of customers who ordered the same product. Okay. So we are talking about the same products. If we see the join of 1st join and that we can see, the order product IDs are same. So that is there. However, there is a subtle flaw present. Okay. Can you spot and explain how it would impact the result? Okay. So they are, moreover, how rectify the screen carry while maintaining the intended purpose. Okay. So I am talking about the subtle flow. What is there here? Ideally, it should be yeah. You can see this thing. So, in the select statement, I can see the customer IDs that we are getting. That is fine. In orders, so we are getting that from order 1, and we are also managing from order 2. And, yeah, the customer so, ideally, the things are okay. So here, one thing we can, make sure if what whoever has not ordered anything. So they will definitely, get a kind of thing where, so they'll not be there part of the particular result set. That is what I can see. Other thing other than that, I can see the query is fine. I don't find any error here. I don't find any issue here. The things are looking good then other than this. Yeah.

So, in the interface segregation principle, this is part of the solid principle. This is a very important part in terms of defining the architecture and in terms of maintaining the code. So, just to implement this thing, it is very necessary to have this kind of thing if we are dealing with third-party services. So one thing I would say, in case of if we are providing third-party services. So what we need to do is prepare a layer around our core development part, using the interface. So, an interface would definitely give you the signature, not the block of words. They will not have a body. They will definitely have a signature. An interface will be used to avoid multiple inheritance features. They will have the multiple inheritance functionality available in the interface. We don't have that in a class. So, that is the main primary difference of it. Secondly, we'll have a block of statements and logical things in a class. An interface will be associated with a class only. So, whatever the class, we have a signature. The same thing will be there for an interface. Ideally, we'll create a separate class library application that will have a reference to this thing, to some third-party services. We can use the same thing for some other application within the same solution. So, for example, if we are creating a class library for one application and the other application project is using that particular class library, they will directly interact with the interface that will have the signature only, to avoid accessibility to this particular block of code. For security purposes, if the third-party application hits that particular interface in place of the class object, that will be kind of thing. They'll hide the logic; they'll not show the logic upfront, and they'll have only the signature. In case of any hacking attempt or in case of any unauthorized access, they will definitely handle this request, and they will not present the logical thing or the code. Or there may be some secret data or some key or some authentication or authorization part handled that will be hidden itself in the class or in a method of a class. So, if we are representing the interface, that would be the interface segregation principle in C#, to avoid this ambiguity of it.

We will have a strategy for deployment, definitely. First, we should have different servers for the application and SQL. As part of 0 downtime, we should have a backup server for it. For example, if we're running with an application server, say server A, and database server, say server D, we need to prepare a backup server. So, in case of DNS management, we have www.xyz.com. We need to create a backup server, say server A point 1, and server A point 1 should have the same replica of code which points to the database server, the same database. If we want to restart the server, we need to just switch the DNS from server A to server A point 1 temporarily. That will take a scheduled 1 minute, and we need to restart the IIS pool for that. That's the only thing we need to do. It will take almost a second. The server configuration is good. We need to make sure of that. Then we need to restart server A. That will take a few minutes. That's fine. But the application will be on for the temporary server, that is server A point 1. We can see the service server. Then we will move to move the DNS from A point 1 to A again once the server is restarted or any issue has occurred. We can do that similar thing. In case of deployments, we need to do a replica of that, or maybe we can have a scheduled job for replicating the code from server A to A point 1. Similarly, we can do for server D, that is a database server. And server D will have, I mean, if you want to restart the things, we need to have regular backups for that. So, SQL server will be a kind of thing where we need to store the data. I mean, same backup restore functionality we need to have at the same time. Because if we are moving database from one server to another server, for example, server D to server D point 1, that will again create an impact in case of maintaining the older data. So, that if the data has entered in between of that execution, that latest data should be stored somewhere with a flag, or maybe we can take a fresh backup of that particular server. We can move that along with the latest backup or latest data to the main server. So, just to avoid data loss, we need to follow this kind of procedure. So, that's another approach to implement 0 time downtime.

What strategies do you use to manage state and data consistently across the distributed system? Okay, so in case of cloud or native application in.NET technology, what strategies we need to do just to maintain the state and the data consistency across the distributed services? So my answer would be if we take an example of an application where we are having multiple applications for a single sort of database. So the synchronization should be real-time. That is one thing. If we are using the same database for multiple applications, for example, one is hosted in the cloud, the other is hosted as a desktop application, and the other would be a kind of backend application that would be again in the cloud. So, we're running with three different applications, we're uploading certain things as a backend that needs to be reflected or at the same time in a frontend website or the cloud application, along with the desktop application. That should be a real-time sync needs to be there, and that is there by default in a SQL Server database, we are running with the ASP.NET application. That is one thing. Secondly, if we want to work with this distributed architecture, at the time, we need to get the real-time data. For example, if we are inserting any data in a backend application. So at the same time, while we are fetching the data, we need to get the fresh data from the SQL Server or from the database just to have the consistency. I mean, what data we have entered in a SQL or in a backend application that needs to be synced at the same time. So we need to get the fresh data at the same time without any latency, without any delays, without any scheduled things. It has to be there with the other application. So across the application, we need to manage that kind of thing. And ideally, we can achieve this approach for a centralized database with the distributed services, which is hosted in a cloud or a native application, that can be managed easily.