Мой первый большой проект был разработан с помощью Object Relational Mapper, который абстрагировал базу данных, поэтому мы сделали все объектно-ориентированным, и было легче отслеживать и исправлять ошибки, а также было особенно легко вносить изменения, поскольку весь доступ к данным и бизнес-логика были Однако в коде C #, когда дело дошло до сложных задач, система чувствовала себя медленно, поэтому нам пришлось обойти эти вещи или перестроить проект, особенно когда ORM пришлось делать сложные объединения в базе данных.
Сейчас я работаю в другой компании, у которой есть девиз: «наши приложения - это просто оболочка базы данных», и у нее есть свои преимущества и недостатки. У нас действительно быстрые приложения, так как все операции с данными выполняются над хранимыми процедурами, в основном это SQL Server 2005, но когда дело доходит до внесения изменений или исправления в программном обеспечении, становится сложнее, потому что вам приходится менять оба, код на C # и хранимые процедуры SQL, так что все равно, что работать дважды, в отличие от того, когда я использовал ORM, у вас нет рефакторинга или строго типизированных объектов в SQL, Management Studio и других инструментах очень помогают, но обычно вы тратите больше времени на это .
Так что я бы сказал, что это зависит от потребностей проекта, если вы не собираетесь хранить действительно сложные бизнес-данные, чем, может быть, вы вообще можете избежать использования хранимых процедур и использовать ORM, который облегчает жизнь разработчика. Если вы беспокоитесь о производительности и хотите сохранить все ресурсы, чем следует использовать хранимые процедуры, то, конечно, их количество зависит от архитектуры, которую вы проектируете, поэтому, например, если у вас всегда есть хранимые процедуры для операций CRUD, вам потребуется для вставок, один для обновления, один для удаления, один для выбора и один для листинга, так как это наиболее распространенные операции, если у вас есть 100 бизнес-объектов, умножьте эти 4 на это, и вы получите 400 хранимых процедур, чтобы управлять самыми основными операций над вашими объектами, так что да, их может быть слишком много.