In the past week, I dove deep into some foundational concepts in.NET development. Here's a breakdown of what I learned, structured to guide anyone wanting to explore this field.
Understanding the.NET Application Lifecycle
The lifecycle of a.NET application represents the sequence of steps an application goes through from initialization to termination. Each type of.NET application, such as console applications, Windows Forms/WPF applications, ASP.NET Web applications, Blazor applications, and Xamarin/MAUI applications, has a unique lifecycle due to its operational environment.
Three Key Concepts in the Lifecycle:
Common Language Runtime (CLR):
Manages the execution of .NET applications.
Handles tasks like code execution (via JIT compilers), exception handling, memory management (garbage collection), and thread management.
Application Domain:
Compilation Process:
First Stage: Converts C# or VB.NET code into Intermediate Language (IL), stored in assemblies (DLLs or EXEs).
Second Stage: At runtime, the CLR converts IL to machine code using JIT compilation.
Lifecycle Stages:
Initialization: The application loads into memory and begins execution, typically starting with the
Main.csfile.Execution: Methods in
Main.csexecute line by line, performing operations like I/O, calculations, or database calls.Termination: Once all code in
Main.csexecutes, the application exits using methods likeApplication.Exit()orEnvironment.Exit().
C# Programming Fundamentals
C# is a multi-paradigm and cross-platform programming language developed by Microsoft and is a descendant of C programming language. It is cross-platform because it can be converted to an Intermediate language which in turn can run on Windows, Linux, or Mac Operating system. C# is a cornerstone of .NET development. Here's a quick overview of access modifiers that govern how classes, methods, and variables interact:
Public: When a class, method, or variable is declared public, it means that it can be accessed by all other classes or methods within the same namespace or assembly Also, it can be accessed by methods in another assembly.
Private: When a class, method, or variable is declared private, it means that they cannot be accessed by all other classes or methods within the same namespace or assembly. The methods and variables can only be accessed from that class alone.
Internal: When a class, method, or variable is declared internal, it means that they can be accessed by all other classes or methods within the same namespace or assembly but cannot be accessed by classes or methods in another assembly.
Protected: When a class, method, or variable is declared protected, it means that it can’t be accessed by all other classes or methods within the same namespace or assembly. They can only be accessed by a class that they are parents to; that is, the only classes or methods that can access them are classes that are derived from them.
Protected Internal: When a class, method, or variable is declared as protected internal, it means that they can be accessed by all other classes or methods within the same namespace provided that those classes are derived from them, and they can also be accessed by other namespace classes that are derived from the namespace where the protected internal class is declared.
Building and Securing Web APIs
What is a Web API?
API generally stands for application programming interface and a web API is a software interface protocol that allows communication between different services, applications, and systems on the web. API provides functionality to clients via HTTP or HTTPS, which enables them to perform various operations like creating data, fetching data, updating resources, deleting resources, etc.
Now, in the context of an ASP.NET application, API refers to using the ASP.NET core framework to build representational state transfer (RESTful) services that are accessible to clients, such as mobile apps, servers, or web apps.
Key Concepts in Web APIs:
RESTful Architecture: Most APIs now are created to follow RESTful architecture, which defines a set of conventions for how HTTP is used. In REST, URLs (which stands for uniform resource locator) are used to represent resources that can be gotten by the client using standard HTTP verbs, which are: GET, PUT, POST DELETE, etc.
Stateless Communication: Web APIs are independent on their own and contain all the necessary things needed to complete a response because they do not store sessions or history in the server, unlike web services. Also, the protocol used for communication for web APIs is the HTTP protocol, while the standard file format for sending and retrieving data is Java Script Object Notation (JSON).
Routing: Routing in Web API defines patterns that can be used to get specific actions. When talking about routes in a Web API, we can have different types of routes for different purposes. E.g., here is a sample of a GET request route: (GET/api/account/12345), and here is an example of a POST request route (POST/api/account). Now, when talking about routing, it is important to note that controllers in.net applications help to handle routing operations by making sure that the HTTP response generated from the URL gets to the specific methods to handle the request before a view is returned to the client. And based on the number of classes we have in our application, we can have different controllers to handle different requests.
Versioning: Versioning is also an important aspect to note in web APIs because as we develop APIs, there can be some changes to be made after an API has been deployed, so to do this, another version called v2 will be developed without disrupting the former functionality of the previous version, thereby leading to a sustainable way to manage codes.
Security: This is also another aspect to note when building APIs, e.g., managing financial applications. Web APIs can implement two forms of security, which are:
Authentication and Authorization using JWT Token (JWT web token) or using Oauths
Using HTTP: This is another way to ensure security by making sure that the data transferred is encrypted.
SOLID Principles for Object-Oriented Programming
The SOLID principles are guidelines for writing scalable, robust, and maintainable code. Here’s a quick rundown:
Single Responsibility Principle (SRP): The single responsibility principle states that a class should only contain properties and methods that are related to the creation of the class. I.e., If we have an account class, the account class should only contain methods or actions that are related to the account, and any actions or methods not related should be instantiated in their class. Also, it further states that a method should only solve a particular problem and that a method should have only a single responsibility. For instance, if we have a method that wants to perform addition, it should only contain codes that do addition alone; subtraction or any other operations shouldn’t be included; instead, another method should be created for them.
Open/Closed Principle (OCP): This principle ensures that a class or methods in a class should be open for extension and closed for modification. I.e., existing codes in a class should not be modified or changed after a version has already been released and has been used by clients; instead, it should be extended and released as another version, ensuring that the former code is not distorted.
Liskov Substitution Principle (LSP): This principle states that derived classes should be substitutable for their base class. I.e., any code that works with a base class should be able to work with a derived class without any difference.
Interface Segregation Principle (ISP): This principle states that a client should not be forced to implement an interface they don't have; rather, the interface should be broken down and segregated based on the application needs, so therefore, when designing a Web API, it is very essential to create different interfaces and implement different methods in that interface based on how they are related. If a particular method does not fit into an interface, another interface should be created, and it should be initialized there. This in turn will ensure that a client will only implement the interface they need, and also, a developer can always implement a particular interface to solve a particular problem rather than implementing an interface that contains what they need and what they don’t need.
Dependency Inversion Principle (DIP): This principle states that high-level modules should not depend on low-level modules but rather both should depend on abstraction. This implies that, for instance, the high-level modules in our codes are the logic of our codes, while the low-level modules are the database operations, and for most cases, the result of most logic is a database operation either to save or update the data in the database. So therefore, an interface or an abstraction is needed to dictate how these two modules would communicate with each other rather than communicating with each other directly, more like the API principle. Also, the principle states that abstraction should not depend on details but rather details should depend on abstraction. This means that if we create an abstraction or an interface, the interface shouldn’t contain details of the implementation but rather, it should contain an initialized method with arguments, while the implementation details should be done somewhere else.
This journey through.NET has equipped me with the tools to build efficient and secure applications while adhering to best practices in software design. If you’re venturing into .NET development, these concepts are an excellent starting point for your learning path.
Attributions
And specifically, I would like to appreciate @SundayOladiran my tutor for the great work done for me.