Script Cascade

  OOP in C# is built around four main pillars: Encapsulation, Abstraction, Inheritance, and Polymorphism. I use encapsulation to protect internal object state — for example, exposing a balance via a method instead of a public field. I use abstraction via interfaces like IPaymentService to decouple implementation from usage. Inheritance helps me reuse base logic, like having a BaseEntity for audit fields. Polymorphism lets me override methods like ToString () or create specialized behavior for different user types in the system. These concepts help me write clean, modular, and maintainable code that’s easier to test and extend.

Hashtable is a non-generic collection that stores keys and values as objects. This leads to boxing and unboxing for value types and requires explicit casting when retrieving values — which can hurt performance and cause runtime errors. Dictionary<TKey, TValue> is the generic, type-safe replacement introduced in .NET 2. It avoids boxing/unboxing, improves performance, and gives compile-time safety. It also integrates better with LINQ and modern . NET features. I always prefer Dictionary in new codebases. I’ve only worked with Hashtable in maintaining legacy systems.

var is a compile-time keyword that allows type inference by the compiler — it’s strongly typed, and the actual type is fixed once assigned. It improves code readability, especially for LINQ or long type names. dynamic , on the other hand, defers type checking to runtime. It's useful when working with COM objects, dynamic JSON, or using ExpandoObject. However, it comes at the cost of performance and no compile-time safety, so I use it only when truly necessary. I prefer using var in most cases because it’s type-safe and gives full IntelliSense support. I use dynamic sparingly — only in places where runtime flexibility is needed

A REST API is a web service that follows REST principles to allow systems to communicate over HTTP using standard methods like GET, POST, PUT, and DELETE . It's resource-based — for example, /api/products would represent a list of products, and /api/products/5 would be product with ID 5. It's stateless, which means each request from the client must contain all the necessary info — the server doesn't store any session state. In .NET, I typically create REST APIs using ASP.NET Core with ApiController , and return responses in JSON format. REST APIs are widely used to power web and mobile apps, and I’ve designed many of them using layered architecture, clean routing, DTOs, and proper validation and error handling. 

To build a loosely coupled and performant system using Entity Framework, I follow clean architecture principles — separating the concerns into layers: presentation, service, and repository. I define repository interfaces for data access and inject them into services. The repository implementation internally uses EF Core with best practices — such as AsNoTracking for read-only queries, DTO projections, and pagination to minimize memory and improve performance. For batch operations, I disable change tracking when appropriate and use bulk SaveChanges() to avoid too many DB roundtrips. I also let the DI container manage DbContext with scoped lifetime to avoid memory leaks. This design gives me flexibility to change the data layer later, improves testability, and ensures that performance is not compromised while maintaining a clean and maintainable codebase.

To manage performance and memory in EF Core, I use several techniques based on the scenario. For read-only queries, I always use AsNoTracking() to avoid unnecessary change tracking. I use projections with DTOs to select only required fields and apply pagination or filtering to avoid loading large datasets into memory. For bulk operations like importing data, I disable AutoDetectChanges and batch SaveChanges() to improve performance. I also watch out for N+1 issues by using Include() or better — projecting related data explicitly. In one of my past projects, optimizing a large reporting query with AsNoTracking() and DTO projections cut down memory by 70% and improved response time by 40%. Finally, I always profile and log the generated SQL to catch expensive queries and ensure proper disposal of DbContext to avoid memory leaks

app.Use() is used to register middleware that can process the request and optionally pass control to the next middleware using await next(). It’s ideal for tasks like logging, exception handling, or authentication. app.Run() is a terminal middleware that doesn’t call next(). Once it's executed, the request ends there. I typically use app.Run() for things like a default fallback endpoint or debugging purposes. Order matters a lot in middleware — anything registered after app.Run() won’t run. Means app.Use execute first if we add app.Use after app.Run then it will not we executed.  

The main difference between .NET Framework and .NET Core is in their platform support, performance, and development focus. .NET Framework is Windows-only and has been around for a long time — it's great for enterprise apps that use WPF, WinForms, or legacy ASP.NET like Web Forms or MVC 5. I’ve worked on many enterprise projects that still run on the full .NET Framework due to dependencies like Active Directory, COM components, or older libraries. On the other hand, .NET Core — now unified under .NET 5 and above — is cross-platform, open source, and more performance-optimized. It supports modern app patterns like microservices, containerization with Docker, and deployment on Linux. I've used .NET Core/.NET 6+ for building REST APIs and containerized services running in Azure Kubernetes Service. One key advantage of .NET Core is the ability to do side-by-side deployments, which allows us to run multiple versions on the same machine — something not possible with the full .NET F...