How to Organize Your ASP.NET Program.cs File

[@antonmartyniuk]

I really like the visuals you make in your videos

[@gui.ferreira]

Thank you, Anton 🙏 I put a lot of work into them, I hope they help.

[@Tamer_Ali]

Thanks Gui, you awesome 👍.Keep going

[@gui.ferreira]

Thanks, will do!

[@iliyan-kulishev]

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 ?

[@gui.ferreira]

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.

[@_iPilot]

Back in days before .NET6 there was a Startup file which slightly helped, but for some reasons it was removed from application template.

[@gui.ferreira]

That’s true, but even on those days, it was a mess.

[@icewolf1911]

Good work

[@gui.ferreira]

Thank you so much 😀

[@codeDotnet]

Thanks

[@gui.ferreira]

Thanks for watching!

[@cryptoeric24]

This is NOT a waste of time!!!!!!!!!!!!!!!!!!!!!!!!!!

[@cosorxndrw]

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?

[@gui.ferreira]

No, that's not the case. Your composition root (something like a web project) will have that dependency.

[@GrzegorzGaezowski]

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".

[@gui.ferreira]

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.