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.
Brilliant! I can't wait to try this on my OCD brother-in-law!
This reminded me of an email prank (from over 20 years ago) that simulated a virus threatening to delete all system files. It had a countdown and a big red Cancel button. It was impossible to click the button as it repelled the cursor, adding to the frustration. When the countdown hit 0, it appeared to start deleting files for around 10-15 seconds, then stopped and gave a warning about the dangers of opening email attachments! My Dad, who normally likes a good joke, was not amused. I'm quite certain I have it saved on a floppy somewhere.
"Go forth into the source" - Neal Morse
"Hope is contagious"
Back around 1975 ± 2 years one of the programmers at the newspaper where we worked wrote a simple program he named GAME1. He put the .SAV (like .exe or .com) file of it (TOPS 10 system) in the system area. When one of the people in the sports department ran it, it printed "Files Deleted" and listed all the files in the area with pauses to make it realistic. Typing control C which would normally cancel a running program caused it to print "I can't do that" and it continued listing files. It had also sent a message to the operator who had been made aware of the program, so when he called for help the operator told him he couldn't kill it. He said later he became physically ill since those files were stories that were supposed to be printed in the next edition. No files were actually deleted and the program exited once the several hundred files in that directory had been listed.
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).
My first thought with anything done by all juniors is did they enforce user roles at the controller/etc level, or just hide links to admin pages but let ordinary users do admin if they found/were given the URL?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
We do not fault dogs for acting like dogs. We intervene and train them patiently and consistently.
Same with junior programmers. They have likely learned the basics through college or other training, but there is so much to learn in the real world. That is why those of us who are team leads and software engineering managers have a responsibility to mentor. Every code review is an opportunity to train. Whomever was leading this project should have managed it so as to keep this from getting out of hand. Topics like SOLID are principles, not laws. It takes engineering expertise, which can be taught, to know how to implement those principles for any given project.
Of course, sometimes a team lead is not given the authority to mentor and manage projects, which can lead to this kind of thing. An old adage that is true in any time frame, is this set of illustrative equations:
Responsibility + Authority = Success
Responsibility - Authority = Failure
It is unfortunate that junior programmers were allowed to roam free. Same when non-engineers manage software projects. Bad things happen.
Last Visit: 31-Dec-99 18:00 Last Update: 15-Jun-21 0:15