Maybe it's time to rethink our project structure with .NET 6 about timdeschryver.dev HOT 24 CLOSED

Outstanding staff.... thank you for sharing this

from timdeschryver.dev.

Sure, go for it @Vadimyan
As long as there's a reference back to this blog post that's fine.

from timdeschryver.dev.

How-to use Logging (like Serilog) in Minimal API ?
Sample Serilog NET 6 minimal API: https://www.anmalkov.com/blog/use-serilog-with-minimal-api-or-aspnet-6

MinimalApiPlayground by Damian Edwards - Program.cs more 500 lines, refactoring?
https://nikiforovall.github.io/dotnet/aspnetcore/2021/09/10/opinionated-minimal-api.html

from timdeschryver.dev.

@kiquenet because that's something that can be shared across multiple "modules", this can be registered in the root. The links you're referring to show how to do this.

from timdeschryver.dev.

What's your take when you have shared projects that may use some of the same code? For example, blazor solutions typically have a .Shared project for reusing models or Dtos. The only solution I can think of is to place Modules in their own project (class library).

from timdeschryver.dev.

@safari137 I think that's fine.
I've also seen it published as (private) NuGet packages, but that was most of the time an overkill and not fun to work with.

from timdeschryver.dev.

Hi, where can I find the code for the module based approach you mentioned here. Thanks.

from timdeschryver.dev.

Sorry @pawanpillai , I don't have a codebase to share for this article.

from timdeschryver.dev.

@timdeschryver I'm curious if you've continued to use this pattern. What do your Endpoint classes look like, and how do you map from the minimal API delegate to the endpoint? I'm trying to understand if there is value in using this approach vs some other library built atop minimal APIs like FastEndpoints.

from timdeschryver.dev.

@dylinmaust Not currently, the project that I'm on already had the architecture in place with controller-based API's. We didn't see a lot of improvements to refactor the codebase compared to the time we would have to invest in it.

However, I still think that project can benefit from this approach. It can be changed here and there (also with new features in .NET 7), but the bigger idea behind still can be applied. It's more about structuring your code and using the features built into .NET (instead of bringing in external dependencies without giving it proper thought). I'm following the FastEndpoints project from a side line, and it's not a "this VS FastEndpoints" approach, but FastEndpoints can be used together with the proposed structure in this blog post.

from timdeschryver.dev.

@timdeschryver I've build a project based on some points you write in these post. You can check it here: https://github.com/kid-cavaquinho/minimal-api
I would love to hear your input.

from timdeschryver.dev.

Great approach! You define the IModule interface with the two functions that are used in the Program.cs to register the modules and endpoints. You showed an example where you make an own Endpoints folder where each endpoint gets its own file. How would you incorporate the IModule interface with that? Should I Create an own interface IEndpoint where you have to imlement MapEndpoints or how should it look like?

from timdeschryver.dev.

@FlorentVllasa thanks for your input. I believe there's still a lot of room for improvement in the sample project I did. In the case you want to add a new module you just need to make sure it inherits from IModule and implements the two methods defined in the interface signature.

With a little help of reflection all the dependencies from a new module should be registered correctly before the builder.Build call and materialized when the application starts to run.

from timdeschryver.dev.

Yes I know but having seperate endpoint classes means that you would not implement IModule from the Endpoint class itself or? An endpoint is not a module semantically speaking.

What I did is create an IEndpoint interface where you need to implement a function RegisterEndpoints. I now have a CreateOrder class that implements the function, basically adds a simple get request. Now I adjust the code in the ModulesExtension so you now have not only a DiscoverModules but also a DiscoverEndpoints function that will be used for the MapEndpoints function inside the ModulesExtension.
Would you say that this is a good approach?

from timdeschryver.dev.

@FlorentVllasa my reasoning to use IModule is based that any module could contain one or more endpoints. A module should be explicit and express what it does and what it needs.

I believe your approach is not wrong, it's just a different way to define the endpoint registration. I would probably not combine both IModule and IEndpoint. Evaluate what makes more sense in your context and what fits best for your application.

from timdeschryver.dev.

Hi, @timdeschryver. I was really inspired by your idea from this article. And I think we may also reconsider looking at what's inside the endpoint handlers. It seems that new bindings to models via attributes and service injection could unify endpoints and make this layer simpler.

I would like to publish a translation of your article on Habr.
You do not have any license for articles listed, so may I ask for permission to publish this? With all the links to original article, of course.

from timdeschryver.dev.

Nice post, but I would abstract IServiceCollection and from module itself by leaving it as minimal as possible. All I could add would be a DI objects that could be injected through module's constructor and shared among the endpoints.

from timdeschryver.dev.

@Vadimyan I forgot to mention it previously.
But I'd also like to add the translation to the page.
You can see an example here, https://timdeschryver.dev/blog/getting-the-most-value-out-of-your-angular-component-tests. Is that fine by you? It should be easy to add, because it's just am additional frontmatter in the source file https://github.com/timdeschryver/timdeschryver.dev/blob/main/blog/getting-the-most-value-out-of-your-angular-component-tests/index.md.

from timdeschryver.dev.

I like that idea @rustam-umarov !

from timdeschryver.dev.

@timdeschryver That's a great idea, thanks for suggesting it. I made a pull request which seems to do what is needed. And thanks again for the great article.

from timdeschryver.dev.

1. In the beginning everything was a class and an instance.
   You could control and debug anything from constructor to destructor.
   For single instances you had the 'Singleton' pattern.

2. Than someone brought up DI.
   Someone also brought up the extension methods - lol !!!

3. And now you can dump DI - and '...becomes easier to "new" instances up instead of relying on the DI container.'

Could we just skip step #2 :) ?

from timdeschryver.dev.

It looks like NancyFx finally had a baby.

from timdeschryver.dev.

Hey Tim,

I liked this idea a lot and rolled it out into a project, where I discovered an issue.

Whilst integration testing the API I started getting some weird exceptions regarding ambiguous routes which confused the hell out of me for a while but of course it is the static RegisteredModules getting populated for each test.

Dropping the static state and altering MapModuleEndpoints as follows seems a nice fix, thought I would share.

public static WebApplication MapModuleEndpoints(this WebApplication app)
{
    var modules = app.Services.GetServices<IModule>();
    foreach (var module in modules)
    {
        module.MapEndpoints(app);
    }
    return app;
}

from timdeschryver.dev.

Good to know, thanks @p-m-j !
If you want, feel free to update the article at https://github.com/timdeschryver/timdeschryver.dev/blob/main/blog/maybe-its-time-to-rethink-our-project-structure-with-dot-net-6/index.md

from timdeschryver.dev.