Journey as a Developer in ASP.Net Framework.

 

Short story on my first application build, well a few first lets say 3 until I realized I was coming at the project wrong so. I came to realize that the MVC framework by it self is quite annoying. After being able to create a simple CRUD application trying to extend it became a real annoying bug after bug. Like when I tried to just add a new function something just has to break for some reason. At this point frustration was real and back of my head I knew looking at Design patterns at a code level ain’t getting me anywhere. Decided to look bit deeper and see if cant find any other framework but also realized I was busy building Monolith apps. Let me show!!

MY First MVC CRUD (Before extension)

It Works! but the design.

Well as you can see they always work but I dare you to extend a Monolith app or just a simple modification by adding search functions in. But all dark clouds have a silver lining at least. I came across Clean Architecture and MVC. Looking at Design Patterns on a File structure point of view simplified a lot of thing’s like. Modifying code and adding new functions easily. By this I mean having a structure where you can either combine the API and the Front End or separate them. By First creating Folder container for all your subfolders called API, Domain, Infrastructure and then your DAL(Data Access Layer). Yes I understand you might say this seems like the Domain-driven-design but they look the same they just called different things.

Clean architecture Design.

What I love about this framework mostly doesn’t matter if you going code first or database first. You can connect a database and remove it if you wish also. But lets get into this bit deeper from what I’ve learned so far.

Domain:

The Domain is basically independent and should not depend on anything or any other subfolders. In your Domain you can place your Models, Abstractions within your Abstract folder that’s where your Repository would be holding your Interfaces. mind you this is where DRY comes to play meaning let say you are doing some get methods it would be great just to create an IRepository of repetitive tasks like GET… just get a type DATA and replace the type with the DATA what you want to get in simple term. Your core layer will define an interface, such as Sender. Your infrastructure layer will depend on the core layer and provide an implementation of the interface, such as a EmailSender. Any class in your core layer which requires to send an email will only depend on the interface and remain ignorant of how it is actually implemented. Therefore, the core layer does not have any knowledge of the technical details of sending an email as they reside only in the infrastructure layer.

Infrastructure:

You can place all your services and logic [example below] along with their models in here. Basically this is the part where separation of concern comes to play here. In a monolith case where all the logic and services could be found in a controller cluttering controllers to a point when you want to remove a add function the thing collapses. You can place your email service here for instance am using sendGrid (note for future just write a console app to activate your api key way simpler that way) but a simple method of implementing sendGrid would be as follow:

SenderOptions Model

Service inheriting IMailService Interface

final sauce of implementation

You can think of this service as a background service that should be called from your program.cs file[if you’re using .Net 6]as background service but in general you are actually just registering that service like so:

builder.Services.AddTransient<IMailService, SendGridEmailService>();
builder.Services.Configure<SendGridEmailSenderOptions>(options =>
{
options.ApiKey = builder.Configuration[“ExternalProviders:SendGrid:ApiKey”];
options.SenderEmail = builder.Configuration[“ExternalProviders:SendGrid:SenderEmail”];
options.SenderName = builder.Configuration[“ExternalProviders:SendGrid:SenderName”];
});

The Services.Configure is just getting string var. from your Secrets.json file. The Transient service basically means like a service lifetime that is in this situation remaining in place but not fully active only when the service is called will it be active and when its finished with its work. so an email service doesn’t need to be active the whole time therefore called a background service running in Transient.

Now you can call your service in your controller as async. that been said if your method is async func.

await _mailServices.SendEmailAsync(message: “text”, subject: “subject”, email: “ ….”);

There’s a lot more to this architecture but thing is its best to use this when you know for sure the project is going to become complex for instance business sites, restaurant site… but for simple forms and prototyping well monolith ain’t so bad I guess untill project gets complex but…