Uso de Store Procedure ( entity framework core parte 2 - usando um banco de dados pré-existente)

Oi Roberto, tudo bem?

Eu concordo contigo. As stored procedures eram muito usadas e praticamente obrigatórias para qualquer desenvolvedor, uns 15 anos atrás. Isso porque o paradigma era "database first", ou seja, o banco de dados relacional era o ponto central de toda aplicação, e acabava concentrando boa parte das regras de negócio. Por isso, muitas vezes as stored procedures e triggers centralizavam boa parte dessas regras. Uma das vantagens desse processo, era poder realizar "hotfix" sem alterar uma linha de código da aplicação! E o preço disso era a possível quebra de regras da aplicação, já que não se aplicam testes de unidade no banco de dados. Assim, o banco de dados acumulava funções como Data Access Layer + Business Logic Layer enquanto a aplicação em si funcionava como "interface do usuário". Porém, com o passar dos anos, apareceram novas formas de persistência de dados: fontes de dados heterogêneas (SQL Server + MySQL + Oracle), NoSQL (MongoDB, Redis, etc.), o que tornou proibitivo incluir qualquer regra dentro de uma procedure de banco de dados. Por isso, atualmente as regras precisam ficar no código da aplicação, o que permite que a aplicação seja desacoplada de um banco de dados específico: você pode estar usando SQL Server hoje, mas eventualmente poderá mudar para MySQL, MongoDB ou SQLite. E o mais importante, as regras de negócio no código e não no BD permitem a testabilidade, através de testes de unidade automatizados e testes funcionais, prevenindo contra possíveis falhas na aplicação.