This is what you get when you have junior programmers write an application in .NET Core
-
A small .NET Core API project... 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... :sigh: 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 X| 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. :laugh: :(( (We're talking just shy of six figures here.)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsMarc Clifton wrote:
it seems like they were hand coded rather than generated by a tool...
No, they were generated by tools. :)
Marc Clifton wrote:
No integration testing to validate business logic.
IOW, they have no idea whether the code implements the required business logic! :omg: I'll bet that connection strings, passwords, etc. are all hardcoded, as well. :sigh: I'm certain that we all wrote bad code when starting out, but this is exceptional!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Marc Clifton wrote:
it seems like they were hand coded rather than generated by a tool...
No, they were generated by tools. :)
Marc Clifton wrote:
No integration testing to validate business logic.
IOW, they have no idea whether the code implements the required business logic! :omg: I'll bet that connection strings, passwords, etc. are all hardcoded, as well. :sigh: I'm certain that we all wrote bad code when starting out, but this is exceptional!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Daniel Pfeffer wrote:
IOW, they have no idea whether the code implements the required business logic!
I might have missed it in all the other boilerplate stuff.
Daniel Pfeffer wrote:
I'll bet that connection strings, passwords, etc. are all hardcoded, as well.
Thankfully not.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
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...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
I have been non stop fighting most time in most of my workplaces, to avoid this kind of over engineering,
Please refer to this as pseudo-over-engineering or pseudo-engineering. This is the type of "architecture" which is actual artifice or facade layer that is totally useless. If the architecture doesn't somehow enable : 1) less code to be written (thus making enhancements and fixes easier) 2) make the code more reusable (and is actually going to be re-used) then it is Crapitecture. Just because some took a doghouse and placed it at the top of a 300 foot tall concrete tower does not make it a skyscraper.
-
Super Lloyd wrote:
I have been non stop fighting most time in most of my workplaces, to avoid this kind of over engineering,
Please refer to this as pseudo-over-engineering or pseudo-engineering. This is the type of "architecture" which is actual artifice or facade layer that is totally useless. If the architecture doesn't somehow enable : 1) less code to be written (thus making enhancements and fixes easier) 2) make the code more reusable (and is actually going to be re-used) then it is Crapitecture. Just because some took a doghouse and placed it at the top of a 300 foot tall concrete tower does not make it a skyscraper.
raddevus wrote:
it is Crapitecture
This new pattern deserves a book written about it! :laugh:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Super Lloyd wrote:
o 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!
Exactly!
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsI 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).
-
A small .NET Core API project... 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... :sigh: 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 X| 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. :laugh: :(( (We're talking just shy of six figures here.)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsSounds like a perfect case for code-generation by a tool, instead of throwing workers at the problem.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
A small .NET Core API project... 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... :sigh: 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 X| 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. :laugh: :(( (We're talking just shy of six figures here.)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsThey just followed the logic. which used to be the best approach? the multi layer approach, they "followed" that. Which used to be the fastest ORM? Dapper, so, it might just be, let's continue using it.
-
A small .NET Core API project... 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... :sigh: 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 X| 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. :laugh: :(( (We're talking just shy of six figures here.)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsMy 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? --Zachris Topelius
-
A small .NET Core API project... 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... :sigh: 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 X| 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. :laugh: :(( (We're talking just shy of six figures here.)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsWe 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. :)
-
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...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
EF is a whole other set of problems.
-
A small .NET Core API project... 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... :sigh: 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 X| 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. :laugh: :(( (We're talking just shy of six figures here.)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
A small .NET Core API project... 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... :sigh: 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 X| 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. :laugh: :(( (We're talking just shy of six figures here.)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
A small .NET Core API project... 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... :sigh: 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 X| 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. :laugh: :(( (We're talking just shy of six figures here.)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
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...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Where was the Lead. The person in charge is to blame, not the junior devs. Mentoring, Design reviews, standards.
-
A small .NET Core API project... 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... :sigh: 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 X| 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. :laugh: :(( (We're talking just shy of six figures here.)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsErrr. That's on you. Don't expect a junior to have a clue. Be a mentor, not an after the fact critic.
-
Errr. That's on you. Don't expect a junior to have a clue. Be a mentor, not an after the fact critic.
mattyltaylor wrote:
Be a mentor, not an after the fact critic.
Oh, I am very much a mentor. Unfortunately I and my team are picking up this project having no knowledge of it until, well, now. So the damage was done a while ago.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions