100 is too many we don't need to name every solution to a problem (pattern). Some of them are language fault but some of them are peoples fault.
Example Service layer pattern from my experience produced a lot of anaemic domain models as people used domain models as data models and did everything regarding business logic inside of a service. It was much easier in most of cases just to use controller -> repository -> domain do some logic -> return to controller -> client. It would be less code and easier to debug.
We need less patterns and more developers thinking about what do we actually need and stop cloning project architectures just because you are used to it. This mainly goes to employers, tech leads, and seniors.
Why do I need to use transformers and such in cases where DTOs will only be copy/paste some fields and ignore others. Maybe sometimes converting numbers to string. Isn't it easier to make DTO constructor that accepts object of some type and extract fields into DTO?
I saw Unit Of Work pattern while working with .NET Core. I never wanted to implement it nor did I need. Created simple repositories (in this case called by many anti-pattern) and used methods to fetch data to avoid wirtting same LINQ many times. Why would I write Unit Of Work? Just because someone wrote a blog about it and now all listed stuff must apply to me?
100 is too many we don't need to name every solution to a problem (pattern). Some of them are language fault but some of them are peoples fault.
Example Service layer pattern from my experience produced a lot of anaemic domain models as people used domain models as data models and did everything regarding business logic inside of a service. It was much easier in most of cases just to use controller -> repository -> domain do some logic -> return to controller -> client. It would be less code and easier to debug.
We need less patterns and more developers thinking about what do we actually need and stop cloning project architectures just because you are used to it. This mainly goes to employers, tech leads, and seniors.
Why do I need to use transformers and such in cases where DTOs will only be copy/paste some fields and ignore others. Maybe sometimes converting numbers to string. Isn't it easier to make DTO constructor that accepts object of some type and extract fields into DTO?
I saw Unit Of Work pattern while working with .NET Core. I never wanted to implement it nor did I need. Created simple repositories (in this case called by many anti-pattern) and used methods to fetch data to avoid wirtting same LINQ many times. Why would I write Unit Of Work? Just because someone wrote a blog about it and now all listed stuff must apply to me?
Hope you see the point I'm trying to make here.
Amen