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 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