The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen.
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
30+ controllers, one for each table.
30+ services, one service per table.
30+ "repositories", one repository per table.
30+ files for constants, basically one constant string definition (ok, maybe 3 or 4) per static class.
30+ files for actual model entities. So why are you using Dapper instead of EF?
The "repositories" are basically passthroughs to the db context for CRUD operations, and because the project uses Dapper, somewhere in the code base is 30*4 SQL statements for each table's CRUD operations.
And given that the controllers, services, and "repositories" are manipulating tables, and it seems like they were hand coded rather than generated by a tool...
And it seems so bassackwards to me. To me, controllers and services should be based on function, not table CRUD operations.
And while I haven't looked at the Angular front-end, I suspect, from what I see of the back-end, that all the business rules are coded in the UI.
So, given that:
No integration testing to validate business logic.
It's actually quite clean, given it all follows a repeated coding style and practice. On the other hand, the lack of abstraction and the lack of any architecture other than the "controller-service" architecture baked into ASP.NET Core API just leaves me feeling sad and depressed.
And you do NOT want to know how much budget this project was given, that has been completely used up and the project is not anywhere near finished. (We're talking just shy of six figures here.)
Well, while I totally agree with what you imply... I have been non stop fighting most time in most of my workplaces, to avoid this kind of over engineering, which seems to be a powerfully widespread gospel... And not just with junior devs...
To this day I still can't understand why people emphatically still "need" a (home made) "Per table Data Repository", when we have EF that take care of it all for you already!
In a way you can't blame the junior dev here, maybe he was using the (socially) safest architecture...
I have nothing against using a repo per table, sometimes I do it. Sometimes, a repo will be for a task or some kind of logical grouping.
90% of dapper is just mapping from a table to a class, hardly any code involved. Even to generate a class to represent a table is trivial.
The advantage for me and working with different levels of developers is that its simple to understand, simple to find the correct repo and method. EF may be different now but for most things I don't need a full ORM and EF was a pain. I'm also perfectly happy writing my own SQL and if I need I can just add it to the repo. I don't see this as over engineering, it's pretty simple.
I used to be into EF but I found it harder and harder to justify it over a micro-orm. It may be different now and easy to setup, configure and use but still it's a layer I don't need.
I also have nothing against lots of controllers but I can't understand it being per table in your example, usually its for the UI and specific task.
I've always found it interesting why people use EF, personally I stopped using it when I couldn't justify to a client why I wanted to use it over PetaPocco (wow not thought of that for a while).
I'm a D (Don't Care) person, it's all the same to me.
I dislike A intensely. and I really do not know why.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
HE can't - he'll have to take it to the Eggbox ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
Last Visit: 31-Dec-99 18:00 Last Update: 19-Apr-21 23:43