Não há uma regra rígida e rápida, mas vejo vários motivos para controlar as transações da camada de negócios:

• 
  Comunicação através dos limites do armazenamento de dados. As transações não precisam ser contra um RDBMS; eles podem ser contra uma variedade de entidades.
  
• 
  A capacidade de reverter/confirmar transações com base na lógica de negócios que pode não estar disponível para o procedimento armazenado específico que você está chamando.
  
• 
  A capacidade de invocar um conjunto arbitrário de consultas em uma única transação. Isso também elimina a necessidade de se preocupar com a contagem de transações.
  
• 
  Preferência pessoal:c# tem uma estrutura mais elegante para declarar transações:a using quadra. Em comparação, sempre achei as transações dentro de procedimentos armazenados incômodas ao pular para rollback/commit.
  

Isso pode ou não ser um problema dependendo de quantas transações estão sendo abertas (não está claro se este é um único trabalho ou um procedimento que é executado com alta simultaneidade). Eu sugeriria olhar para quais bloqueios estão sendo colocados em objetos e por quanto tempo esses bloqueios estão sendo mantidos.

Tenha em mente que a validação possivelmente deve trancar; e se os dados mudarem entre o momento em que você os validou e o momento em que a ação ocorre?

Se é um problema, você pode dividir o procedimento incorreto em dois procedimentos e chamar um de fora de um TransactionScope .