walter_wiggles
Are you sure? It looks a lot like yesterday’s moon…
- See GetOffMyLan’s comment. An application will have a finite set of queries it needs to make. Depending on the complexity you may have to enumerate them, but sometimes you can build them up dynamically, or even come up with SQL that will cover multiple cases depending on parameter values.
- I think GetOffMyLan’s advice applies here too.
When you’re creating a layered architecture you want to limit a lower layer from knowing what’s above it. If you tightly couple your data layer to the view then you lose flexibility. Imagine having to implement some batch processing features that don’t involve the web.
A lot of this is overkill for a small app so if some it seems pointless it may be because there isn’t a team of devs working on the same codebase.
The repository is responsible for talking to the db. Services are where your business logic lives (and ofc there’s always some leakage of logic into the db).
It’s ok for a service to call other services and multiple repositories, but a repository should only talk to the db. It should not call other repositories or anything else.
It’s ok to rely on db constraints for validation checking.
I’m not too familiar with EF specifically, but I’ll give you my general advice:
- Column filtering can be done in either the repository or service layer.
- Your transaction should be scoped to the service method. MovieService should call both repositories.
- Prefer filtering in the repository
- I don’t know this one
I hate how this is written as if it’s consumers who are responsible for inflation–if we would just stop buying things inflation would go down, hurr durr…
The narrative for the last couple years is that companies have no other choice but to raise prices, but now that people are too poor to afford essentials they magically find a way to lower pieces.
FinCEN is going to shit a brick.
You can do it if you follow these 2 rules: be attractive and don’t be unattractive.