How to Organize Your ASP.NET Program.cs File
ฝัง
- เผยแพร่เมื่อ 30 พ.ย. 2024
- Join me as I show you how I organise my Program.cs in large ASP.NET Applications
💎 Be a Patreon to get the source code: / gsferreira
🚨 KEY LINKS
🤝 Support me on Patreon (and get access to source code) here: / gsferreira
💌 Free Developer Insights: guiferreira.me...
📘 Courses: guiferreira.me...
👨🏫 Workshops: guiferreira.me...
🔗 GET IN TOUCH
LinkedIn: / gferreira
Twitter: / gsferreira
GitHub: github.com/gsf...
Get my newsletters: guiferreira.me...
Visit my blog: guiferreira.me
👋 WHO AM I
Hey! If you're new to my Channel, I'm Guilherme. Call me Gui. I'm a Minimalist Software Craftsman. What do I do here? I share tips on how to simplify your life as a Developer.
#dotnet #csharp
I really like the visuals you make in your videos
Thank you, Anton 🙏 I put a lot of work into them, I hope they help.
Thanks Gui, you awesome 👍.Keep going
Thanks, will do!
With regards to composing the features - are you a fan of defining some interface like IComposer { void Compose(IServiceCollection services)} which all the features implement and then finding the implementations via reflection in Program.cs ?
I like it when I have many features built by different teams.
By having the Interface I can dynamically discover features and avoid some conflicts.
However, in my opinion, it often is an overkill.
Good work
Thank you so much 😀
So you're coupling your Features/UseCases and the project they're in (Application which is below Infrastructure) to your DbContext which is in the Infrastructure project. Isn't that a big NoNo, in the sense that arrows should point inwards?
No, that's not the case.
Your composition root (something like a web project) will have that dependency.
Thanks
Thanks for watching!
Back in days before .NET6 there was a Startup file which slightly helped, but for some reasons it was removed from application template.
That’s true, but even on those days, it was a mess.
This is NOT a waste of time!!!!!!!!!!!!!!!!!!!!!!!!!!
devs: I want to use DI container over manual composition because it's declarative and flat, no methods, conditions, nesting etc.
also devs: this declarative code looks bloated, let's extract some methods for better readability
also devs: now that I extracted the methods, adding the same registration twice is more risky, let's add some if(registered) conditions inside these methods. Better yet, let's make a special "try" method for that.
Btw the one thing this approach lacks compared to manual composition is that there is no encapsulation of objects between the "features". I could move a registration from one "feature" to another and everything would still work, no real boundaries. I find it much more powerful to model "modules" or "features" as objects (mini-composition roots), compose each of them manually and only make these objects expose the dependencies that are meant to be consumed by other "features" or "modules".
I agree with most of your points. I like Modules to create structure and clear boundaries. However, in my experience, it's easier to convince developers to implement small improvements, because we are used to the traditional way of doing it.
Thanks for sharing your thoughts! It brings an important perspective.