✅ .NET Core N-Tier API Project question about repository pattern.
Hi, I am creating a web api project using n-tier architecture, I have API, Entities, DAL(Data access) and Services layer. I have implemented generic repository in DAL layer and now I am creating services in Service layer. I was thinking of a architecture which API layer communicates with Services layer and Services layer With DAL which also has a project reference to Entities layer. But in this way I have to do it like in the picture "new repository()" I added but some say it is bad to use it like this. What is best approach?
94 Replies
Please ignore constructor parameter, its without a parameter actually
You are ignoring the constructor parameter
userRepository
which seems... odd
okay just saw your comment, well why is it without a parameter?
you definately should be injecting a repository into your service, if you're going to have repositoriesI am a newbie and very lost, I searched for tutorials using n-tier architecture and repository patttern but cannot find any resource
how on earth
So it should be like this am i correct?
there are more tutorials for both of those things than there are programmers
yes, kinda
but the only reason I can think of why you would do this is to support unittests, so I'd expect to see interfaces for both the repository and the service
And register this service on my API layer?
its my own personal opinion that N-tier and generic repositories (assuming its over EF Core here) are a waste of time and not a very good pattern
I have interface for GenericRepository and specific repositories which extends from GenericRepository
:/ I have asked to do this in this way that is why
right, but your UserService is hard-coupled to your UserRepository
I am doing a internship for a small company
you should be using the interface here
IUserRepository
etc
okay thats fine
but you should be requesting the repository interface in your service
and storing that, not the concrete implementationSo I should create a interface too for repositories
this is the current architecture btw
repository, and service too if you wanna go full N-tier :p
everything should have an interface, so it can be mocked/stubbed/whatever for tests
and each "module" (DAL, Services) should have its own extension method for
IServiceCollection
like services.AddMeetingAppDAL();
and services.AddMeetingAppServices();
so you can distribute your DI setupI am more lost now lol
But will consider your advices thank you very much for helping,
okay, well https://discord.com/channels/143867839282020352/1150801248027693176/1150808203551051876 is a good startingpoint
sepp
Quoted by
<@105026391237480448> from #.NET Core N-Tier API Project question about repository pattern. (click here)
React with ❌ to remove this embed.
you can go nuts on the interfaces later
the idea is that you "inject" all your dependencies and never
new
it upI got stuck again lol, do I need to register dbcontext and repository in my API layer? It feels like nonsense to me since I think that I shouldn't expose DAL layer to API layer
yes you need to register it, how else would the service provider be able to resolve them
and you're not really exposing the DAL to the API layer just because you are registering it in the service collection before your application even starts
See, this is why I hate N-tier architecture. People get so caught up on "following the rules" of the architecture instead of actually thinking about what is going on 😦
So setting a project reference from API layer to DAL is not a problem right?
yes, you can't get away from that
If I do that everything will be solved in my mind lol
I was too worried about seperation :/
your entrypoint will always need to reference more or lesss everything
because its the entrypoint to your entire program :p
Oh okay then 😅
but yeah, I still suggest you use extension methods for each of your modules, so they can do their own setup in their own packages
and you just call that one
.AddMeetingAppDAL();
method in your APIOut of curiosity what would you rather recommend then?
Instead of N-tier? VSA, all day long
if you "need" an enterprise level architecture at all, VSA is imho the best one
Can’t really find anything related online apart from something engineering related any possible examples?
but honestly, I'm not sure even thats needed. These days I just build everything on a command/handler pattern and then everything else is just whatever I need to invoke my commands
ie, am I making an API? I need some controllers/minimal api endpoints
am I making a CLI? I need a way to handle console commands -> domain commands
Vertical Slice Architecture. The talk by Jimmy Bogard (https://www.youtube.com/watch?v=5kOzZz2vj2o) and Derek Comartins video (https://www.youtube.com/watch?v=L2Wnq0ChAIA) are both excellent
These opinions are based on writing and maintaining 3 500K+ LOC enterprise-scale projects. 2 of them started as onion and eventually moved to VSA, and the last one started with command handlers from the start.
I had a period where I loved onion and was like "oh yeah this is so good"
I think a general issue with cs architecture is how much abstraction there is
It is generally very easy to get lost in the code especially in the place I worked at
I believe they used N tier I’m not sure tho because I’m not too familiar with architectures (junior dev position)
but eventually you just have tons and tons of services with 70+ methods, and you must have an interface for everything you make just so it can be mocked...
Yes that….
absolutely
It just became a pain in the ass
Their entire development seemed like a giant waste of time to me
Because everything was so so abstract
if you move from that to command/handler, each individual method becomes a command and a handler, more or less. At least the ones you call from apis
the good thing here is that you can then move these around however you want. We usually group them in namespaces related to what they operate on
so instead of 70 methods, you have 70 classes, but they can be split and moved as you see fit
I believe you ve seen my code how I put logic in the controllers which from what I heard shouldn’t be done any advice on what I could do there
and a nice dispatcher with pipeline support means you can easily add cross-cutting concerns as middleware, like transactional security
Right now since it’s a personal project I’m not gonna bother moving all of it but for future reference
or global exception handling
depends. If its a smaller project, I'd probably consider using
FastEndpoints
instead of controllers, and have my logic in the endpoint handlerFastEndpoints? and no its a larger project
will have to look into fastendpoints tho
third party library that wraps minimal APIs
its very fast and very readable
oh damn
im reading it rn
yeah thats alot nice for smaller scale apps
it takes a bit of getting used to, but its very nice
I'm more talking like what you d do with this
because what I was told at my old work place is to never put logic in the controller
rather to abstract it to another service layer
which im not too keen on because thats just creating another service for no reason
yeah, thats a very common idea
exactly
there is a potential reason to do it thou
I understand in terms of re-usability yes
to separate HTTP concerns from business concerns
I see
and re-usability for future, like making a CLI invoker for your app
I se eyeah
Though I think alot of companies have gotten too worried with abstraction and stuff like that
actual real-world thing: I wrote a CLI that can import patients into our big HL7 E-health platform
its a massive fucking webapp, with tons of events and stuff happening when registering patients
but we wanted to import a CSV of patients for a new customer
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
so I slapped together a CLI that can run our commands, took me 2 hours
idk if u saw how amazon switched from micro arch to monolith and it massively improved speed
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
right
oh, you have an MVC app that you are adding an API to?
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
right
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
yeah thats when you need that kind of abstraction.. oh
well if its laravel you dont share any code anyways
you have to re-implement the logic
since its two different languages
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
Oh sorry, new person
you are doing the API and the "MVC" part both in laravel
I have another concern with this, for example if I was to return a status type I believe I have to do some weird generic return type of stuff then return the value
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
I thought you were doing the API in C# and the MVC was laravel 😄
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
thats if i was to put the logic at service
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
not sure how you guys go aboutr that
I actually have an example for this. wait a sec
this combines result types with a command runner
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
not a fan of exceptions
very slow very annoying to deal with down the line
try catching everything
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
still, better ways of doing it like this
Also ty, why are you using a Mediator there if I could ask
I vehemetly disagree with this take
my old company did this
made me wanna kms
global exception handler means your entire codebase must use a uniform exception set, or be made aware of HTTP specifics
both are bad
because I need a command executer. Mediator is perfectly fine.
I see
This is the source-genned version, not that you can see that 😄
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
yeah its a bit of an eye opener
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
granted, we still have a global exception handler
just in case an exception leaks
but it just logs and returns 500
If I oculd ask what you mean by http specifics or uniform exception set
fuck I'm late, I'll be back in 20
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
I see
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
Back
that example uses
RemoraResults
which is nice and easy to use, but has a tradeoff - it doesn't explicitly list all error types in its type declaration, like a OneOf
would
but you can use whatever you prefer
in this case, it looks like
By "uniform exception set" I mean that every single exception that might leak all the way to the global exception handler, the handler must be aware of and know how to map to a HTTP response code
"UserNotFoundException" => 404 is easy enough, but what about "InvalidOperation"?
and if you ever add a new exception, you must remember to map it
okay, but lets say you see how fragile that is, so you go with a system where you limit the number of exceptions you're allowed to throw to a fixed set:
NotFoundException
BadRequestException
etc
well, now your entire codebase is HTTP aware
is this a problem? Up for you to decide, but imho its not very nice when my domain logic is concerned about what http status code should be thrownPobiega sorry to cut off topic any chance you could look into https://discord.com/channels/143867839282020352/1150807212017602742 having some issues with EFC maybe you know the anwser