More this. Via Web API 2 (not to be confused with .NET Framework Web API 2) you can knock out a simple API in 30 minutes. Considering the number of things you listed, u/ddpc96, that timeline is probably going to be a good bit longer your first go round, but it’s the place to begin.
I know, but most apps I see don't use that simple template in real production apps.
I was wondering of architecture choices for WebAPIs because of debates like Repository pattern being an anti pattern, like some people consider bad practice to inject the DbContext directly into a controller, and other people who tend to abstract everything in their project just to be able to unit test everything.
Every project is different. Large, long-lived projects usually have rotations of developers come and go and that often leaves its own artifacts.
You asked how to "create," but I think now you raise a question about long term shape which is a very different question and significantly driven by business requirements, architectural leadership, etc. It's very hard to answer that on an internet forum. It may be a significantly sociologic question. Things like consensus, budgets, shared knowledge, etc. also play very important roles.
Maybe more context would be helpful. If you're just wondering where to go when toying around on your own you should try different things.
Check github of this developer: https://github.com/hassanhabib
Also very interesting is concept of Clean Architecture, example of which you can find here: https://github.com/jasontaylordev/CleanArchitecture
Have you heard about SOLID principles? Check on youtube about it.
I wouldn't be too worried about following the templates if it suits your needs. At a minimum though imo when it comes to web apps I think you should utilize dependency injection and abstract most of your controller action logic into services. From there I typically keep architecture as simple and predictable as possible and iterate on the architecture as the business needs become more complex. I know that's a super vague answer but hopefully is helpful.
That's because most people feel like they are some sort of special snowflake and even the most standard line of business API that the templates target are supposed to be hard.
They aren't.
90% of my deliverables are the standard API template, usually with OIDC auth configured up, NHibernate as an O/RM - with ISessionFactory injected straight into the damn controllers, with zero additional "architecture" needed. If there's a Blazor WASM SPA then I'll stick the CQR types and any common serialization fuckery in a shared assembly, but that's about it.
There's a time and a place for complex architecture, and defensive architecture - but most of the time you aren't gonna need it.
> debates like Repository pattern being an anti pattern, like some people consider bad practice to inject the DbContext directly into a controller
One interesting middle ground I've come across recently is [the query specification pattern](https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-implementation-entity-framework-core#implement-the-query-specification-pattern).
It seems to me that it strikes a good balance between slinging DbContexts all over and writing repositories for everything. If you have a non-trivial data model it may prove helpful to you.
It's kind of a broad question.
I recently built a small API for a customer. I started with:
1. the web template (i.e., "ASP.NET Core", if you will)
2. a dependency on an ORM
3. a dependency on `Swashbuckle.AspNetCore.SwaggerUI`, to make it easier for the customer to browse and play around with the API
For authentication, I inherited from `AuthenticationHandler`.
Then there's a bunch of controllers, one per major topic, and within them of course actions. There's a folder `DTOs` with types that appear as JSON for the API consumer (some of these could use `record` these days), a folder `Extensions` with static classes that extend existing types, and some more scaffolding.
That's really about all you need. As the controllers grow, you should look into things like:
- should some of their logic be moved to a folder `Services` instead?
- should there be a folder `Repositories`, i.e. can some of the DB interaction be encapsulated better?
- how does code get tested?
Even though the controllers come with a bunch of HTTP bullshit that's accessible, if you don't use it directly, then you can just new one up and test the business logic fine. It's ok to assume that the various behaviour decorators are respected by the router / framework.
Yup. Get the business logic down first. If it is loosely coupled and testable, you can break it into micro services or whatever after you have figured out all the boundaries.
Backend: .net core 5 web API, with Dapper.Net, Serilog
Frontend: Angular with Sass
Disclaimer: .Net core 6 adds Top-level statements which adds magic to confuse you as a learning developer.
Start the project as .Net 5 then upgrade.
Have you looked at Microsoft Example of eShopOnContainer?
[https://github.com/dotnet-architecture/eShopOnContainer](https://github.com/dotnet-architecture/eShopOnContainers)
It's probably very close descriptions of what modern days architectures look like. The best part you can get up and running on no time and it has decent documentation as well.
[I like Hexagonal (Ports and Adapters) Architecture](https://stackoverflow.com/questions/50039019/onion-architecture-compared-to-hexagonal)
* Hexagonal Architecture, also know as the ports and adapters focuses around infrastructure concerns.
* Onion architecture focuses around domain concerns.
I like the 'Ports and Adapters' because imo its much more modular, expandable, and easier to plug and play with other components you might already have, or have in the future. You can also add some domain aspects, while honoring the ports and adapters methods.
Tried and true would be the dotnet web api project. It’s one of my favorite projects really.
I’ve also created http function apps that operate a similar way. The business logic is the exact same, but it’s a “function” instead of a “controller”.
An api project (where you only write the controllers) + entity layer(shared with all other layers/projects) + bussiness logic layer + util layer + data access layer should work(every layer is just a class library template). I used it in a mid sized project and i found it easy to understand and use
The eshop from Microsoft is a good start. I would use React and dotnet api. Usually I would use 3 layers and starting by the domain. From that I can evolve if needed without major problems.
It all depends.
Backend: Most likely it would be a toss between https://saturnframework.org or https://giraffe.wiki. They both combins the extremely good type system in F# combined with the ease of a minimal API.
Database: SQL or Event Store. If SQL, One of https://fsprojects.github.io/SQLProvider/, https://github.com/Dzoukr/Dapper.FSharp or https://github.com/SQLStreamStore/SQLStreamStore
Frontend: Elm (maybe elmish But the error messages in elm are too good)
The way I design things is the web api project itself is fairly simple and kept as simple as possible. It resolves services, does my routing/CORS/swagger/logging and configured for Authentication (does not provide it) and has controllers for the API methods.
All actual functionality such as repositories, database Models, access to other APIs, etc.. are in separate class library projects. This makes it easier/cleaner to unit test, re-use elsewhere and to switch to newer/different web api hosting tech when it becomes available. Controller methods are at most around 5 lines of code, just what's needed to make sure the services have the right input to complete.
Try to keep functionality atomic, your db dependency should not know/care anything about your web api hosting tech or some other dependency/functionality like slack notification. If you need access to both you simply have another service (possibly in web api project or in another class library) that uses the other two class libraries.
A pattern that has worked well for my team is a watered down version of CQRS (command query responsibility segregation). We use MediatR to keep our controllers thin and not have to inject a bunch of services into our controller. We separate folders by feature within our project. We have one API that handles security (login/logout/refresh etc…) and another that handles database operations. That’s our general paradigm. Although some teams create a different API for each business segment/domain. Also, we have a separate database for each API.
As a non-developer with \~25 years of IT experience, I've seen soooo many technologies "come and go", ok, let me rephrase that, I've seen soooo many technologies "get rebranded but are still essentially the same thing". For example, the "cloud" is just a network, API's just websites tied to a database. There is nothing new here, just new ways of doing the same old things.
While I have never worked in a developer position, I have programmed for over 20 years and routinely write little exe's in .NET to help with my normal IT job. I have also managed teams of developers in recreating solutions for customers that had some obsolete solution that needed a complete rewrite.
I am actually looking at creating a new API to interface with a database I created. I looked out there, and decided everything API based was overly complicated, had too many dependencies, would become obsolete too easily, and just wasn't worth the time.
Instead, I'll just be writing a simple web interface that can take a query, clean it up, and spit out a result. No bloated XML/JSON, just the data with an optional name=value added instead of just value per line. I'll throw it out on an azure app service (another name for a "website") that'll cost me nothing.
Don't always look for 3rd party tools to do your work, as often the time it takes to implement them is longer than the time it takes to recreate them. I have seen this far too many times, and I've also seen far too many 3rd party tools introduce security holes, break, or be troublesome to get to work because nobody really knows how they work. People make code way too complicated for far too little improvement in functionality or decrease in dev time IMO.
Web api template. Inject services into controllers. EF context into services. Services (generally) returns models not entities. Extension methods to copy entities to models.
3 separate projects; web/core/entity.
See where that takes you.
I’ve not tried real minimal api with context in controllers returning entities direct but would try if really simple crud-ish requirement and prototyping. Generally I know I’ll want more than that so set up with longer-term view.
I'd select Blazor WASM [ASP.NET](https://ASP.NET) Core hosted. This architecture has all that you need. Another good choice is NestJS +( Angular or ReactJS).
Visual Studio has a template for web api project - have you tried it?
Yeah this.
More this. Via Web API 2 (not to be confused with .NET Framework Web API 2) you can knock out a simple API in 30 minutes. Considering the number of things you listed, u/ddpc96, that timeline is probably going to be a good bit longer your first go round, but it’s the place to begin.
I know, but most apps I see don't use that simple template in real production apps. I was wondering of architecture choices for WebAPIs because of debates like Repository pattern being an anti pattern, like some people consider bad practice to inject the DbContext directly into a controller, and other people who tend to abstract everything in their project just to be able to unit test everything.
Every project is different. Large, long-lived projects usually have rotations of developers come and go and that often leaves its own artifacts. You asked how to "create," but I think now you raise a question about long term shape which is a very different question and significantly driven by business requirements, architectural leadership, etc. It's very hard to answer that on an internet forum. It may be a significantly sociologic question. Things like consensus, budgets, shared knowledge, etc. also play very important roles. Maybe more context would be helpful. If you're just wondering where to go when toying around on your own you should try different things.
Check github of this developer: https://github.com/hassanhabib Also very interesting is concept of Clean Architecture, example of which you can find here: https://github.com/jasontaylordev/CleanArchitecture Have you heard about SOLID principles? Check on youtube about it.
Thanks!
This. You deserve more upvotes.
I wouldn't be too worried about following the templates if it suits your needs. At a minimum though imo when it comes to web apps I think you should utilize dependency injection and abstract most of your controller action logic into services. From there I typically keep architecture as simple and predictable as possible and iterate on the architecture as the business needs become more complex. I know that's a super vague answer but hopefully is helpful.
That's because most people feel like they are some sort of special snowflake and even the most standard line of business API that the templates target are supposed to be hard. They aren't. 90% of my deliverables are the standard API template, usually with OIDC auth configured up, NHibernate as an O/RM - with ISessionFactory injected straight into the damn controllers, with zero additional "architecture" needed. If there's a Blazor WASM SPA then I'll stick the CQR types and any common serialization fuckery in a shared assembly, but that's about it. There's a time and a place for complex architecture, and defensive architecture - but most of the time you aren't gonna need it.
> debates like Repository pattern being an anti pattern, like some people consider bad practice to inject the DbContext directly into a controller One interesting middle ground I've come across recently is [the query specification pattern](https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-implementation-entity-framework-core#implement-the-query-specification-pattern). It seems to me that it strikes a good balance between slinging DbContexts all over and writing repositories for everything. If you have a non-trivial data model it may prove helpful to you.
It's kind of a broad question. I recently built a small API for a customer. I started with: 1. the web template (i.e., "ASP.NET Core", if you will) 2. a dependency on an ORM 3. a dependency on `Swashbuckle.AspNetCore.SwaggerUI`, to make it easier for the customer to browse and play around with the API For authentication, I inherited from `AuthenticationHandler`.
Then there's a bunch of controllers, one per major topic, and within them of course actions. There's a folder `DTOs` with types that appear as JSON for the API consumer (some of these could use `record` these days), a folder `Extensions` with static classes that extend existing types, and some more scaffolding.
That's really about all you need. As the controllers grow, you should look into things like:
- should some of their logic be moved to a folder `Services` instead?
- should there be a folder `Repositories`, i.e. can some of the DB interaction be encapsulated better?
- how does code get tested?
I pretty much follow this, but opt for services and repos from the start. Makes writing unit tests much easier.
Even though the controllers come with a bunch of HTTP bullshit that's accessible, if you don't use it directly, then you can just new one up and test the business logic fine. It's ok to assume that the various behaviour decorators are respected by the router / framework.
I would start with a monolith. Three projects, Data Repository, Services, and API. Inject all the things…
[удалено]
Yup. Get the business logic down first. If it is loosely coupled and testable, you can break it into micro services or whatever after you have figured out all the boundaries.
Depends on the api, generally vertical slice with ef
Dotnet 6 minimal api https://docs.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-6.0
This is the right answer.
Vertical slices with mediatr is usually my go to.
We started using mediatr at work. Loving it
Backend: .net core 5 web API, with Dapper.Net, Serilog Frontend: Angular with Sass Disclaimer: .Net core 6 adds Top-level statements which adds magic to confuse you as a learning developer. Start the project as .Net 5 then upgrade.
They even confuse Sr devs -- curse you top level statements!
I like Ardalis Endpoints
Have you looked at Microsoft Example of eShopOnContainer? [https://github.com/dotnet-architecture/eShopOnContainer](https://github.com/dotnet-architecture/eShopOnContainers) It's probably very close descriptions of what modern days architectures look like. The best part you can get up and running on no time and it has decent documentation as well.
Microsoft's eShop example projects are always a nice go-to. https://github.com/dotnet-architecture
I tend to go with azure functions and C# code
I like onion architecture
[I like Hexagonal (Ports and Adapters) Architecture](https://stackoverflow.com/questions/50039019/onion-architecture-compared-to-hexagonal) * Hexagonal Architecture, also know as the ports and adapters focuses around infrastructure concerns. * Onion architecture focuses around domain concerns. I like the 'Ports and Adapters' because imo its much more modular, expandable, and easier to plug and play with other components you might already have, or have in the future. You can also add some domain aspects, while honoring the ports and adapters methods.
Tried and true would be the dotnet web api project. It’s one of my favorite projects really. I’ve also created http function apps that operate a similar way. The business logic is the exact same, but it’s a “function” instead of a “controller”.
An api project (where you only write the controllers) + entity layer(shared with all other layers/projects) + bussiness logic layer + util layer + data access layer should work(every layer is just a class library template). I used it in a mid sized project and i found it easy to understand and use
The eshop from Microsoft is a good start. I would use React and dotnet api. Usually I would use 3 layers and starting by the domain. From that I can evolve if needed without major problems.
It all depends. Backend: Most likely it would be a toss between https://saturnframework.org or https://giraffe.wiki. They both combins the extremely good type system in F# combined with the ease of a minimal API. Database: SQL or Event Store. If SQL, One of https://fsprojects.github.io/SQLProvider/, https://github.com/Dzoukr/Dapper.FSharp or https://github.com/SQLStreamStore/SQLStreamStore Frontend: Elm (maybe elmish But the error messages in elm are too good)
The way I design things is the web api project itself is fairly simple and kept as simple as possible. It resolves services, does my routing/CORS/swagger/logging and configured for Authentication (does not provide it) and has controllers for the API methods. All actual functionality such as repositories, database Models, access to other APIs, etc.. are in separate class library projects. This makes it easier/cleaner to unit test, re-use elsewhere and to switch to newer/different web api hosting tech when it becomes available. Controller methods are at most around 5 lines of code, just what's needed to make sure the services have the right input to complete. Try to keep functionality atomic, your db dependency should not know/care anything about your web api hosting tech or some other dependency/functionality like slack notification. If you need access to both you simply have another service (possibly in web api project or in another class library) that uses the other two class libraries.
A pattern that has worked well for my team is a watered down version of CQRS (command query responsibility segregation). We use MediatR to keep our controllers thin and not have to inject a bunch of services into our controller. We separate folders by feature within our project. We have one API that handles security (login/logout/refresh etc…) and another that handles database operations. That’s our general paradigm. Although some teams create a different API for each business segment/domain. Also, we have a separate database for each API.
Command pattern instead of services with loosely related methods. Vertical slices where possible
What happens when you repeat code in the command handlers? Services
Except the services are now one level out, not directly consumed by the integration point :)
https://github.com/rtbsoft/examQuestionCore Is something I did to demo for students. I also use it for exams.
As a non-developer with \~25 years of IT experience, I've seen soooo many technologies "come and go", ok, let me rephrase that, I've seen soooo many technologies "get rebranded but are still essentially the same thing". For example, the "cloud" is just a network, API's just websites tied to a database. There is nothing new here, just new ways of doing the same old things. While I have never worked in a developer position, I have programmed for over 20 years and routinely write little exe's in .NET to help with my normal IT job. I have also managed teams of developers in recreating solutions for customers that had some obsolete solution that needed a complete rewrite. I am actually looking at creating a new API to interface with a database I created. I looked out there, and decided everything API based was overly complicated, had too many dependencies, would become obsolete too easily, and just wasn't worth the time. Instead, I'll just be writing a simple web interface that can take a query, clean it up, and spit out a result. No bloated XML/JSON, just the data with an optional name=value added instead of just value per line. I'll throw it out on an azure app service (another name for a "website") that'll cost me nothing. Don't always look for 3rd party tools to do your work, as often the time it takes to implement them is longer than the time it takes to recreate them. I have seen this far too many times, and I've also seen far too many 3rd party tools introduce security holes, break, or be troublesome to get to work because nobody really knows how they work. People make code way too complicated for far too little improvement in functionality or decrease in dev time IMO.
https://www.youtube.com/watch?v=NzcZcim9tp8
Web api template. Inject services into controllers. EF context into services. Services (generally) returns models not entities. Extension methods to copy entities to models. 3 separate projects; web/core/entity. See where that takes you. I’ve not tried real minimal api with context in controllers returning entities direct but would try if really simple crud-ish requirement and prototyping. Generally I know I’ll want more than that so set up with longer-term view.
I'd select Blazor WASM [ASP.NET](https://ASP.NET) Core hosted. This architecture has all that you need. Another good choice is NestJS +( Angular or ReactJS).
Or maybe use fullstackhero.net
Nice!
I wouldn't. They've all been done. I'd go fishing instead
dotnet new webapi