Ouvindo Opiniões

Na abertura desta discussão, o próprio Edu nos comenta "Certamente não existe uma opção 'correta', mas sim a mais adequada para um determinado cenário", e eu concordo plenamente com isso. A regra pode estar em qualquer lugar, o que deve ser levado em conta é o ambiente onde a aplicação se encontra e a expertise dos profissionais envolvidos. Claro que tudo isso deve estar dentro de uma organização coerente.

Vou relatar aqui algumas das minhas experiências em relação a este tópico. Atualmente, trabalho em um sistema que conta com um software desktop feito em Delphi e um portal desenvolvido em C#, isso tudo ligado em um mesmo banco de dados. Optamos por estas tecnologias justamente pela nossa expertise, como discutido no tópico anterior. Ainda não temos na web a agilidade do desenvolvimento de um sistema desktop, principalmente se estivermos falando de Delphi, mas em contra partida, sabemos que a melhor forma de distribuir um sistema de grande abrangência é pela web. Mediante este cenário, precisávamos de algo que nos permitisse criar regras que fossem comuns as duas plataformas e que as manutenções ocorressem apenas em um local. Utilizamos como banco de dados o MS SQL Server. Ai você já deve estar pensando, "Pronto!!! Coloca tudo em StoredProcedure, certo ?!?" Até poderia, se nosso processo de alteração de estrutura de banco não fosse extremamente burocrático. Isso ocorre porque somos auditados por órgãos federais que exigem que toda e qualquer alteração no banco de dados seja muito bem documentada e onde a base de produção seja apenas acessada pelos usuários via sistema ou pelo próprio DBA. O que também causaria uma sobrecarga no DBA. E também não podemos deixar qualquer estagiário maluco fazer estas StoredProcedure, pois um erro de lógica poderia pendurar todo o banco.

Multi-Camadas também não seria nosso caso, pelo menos não utilizando DataSnap, pois estamos lidando com plataformas diferentes. Não estou familiarizado com o desenvolvimento multicamadas do .Net, não sei como seria consumir isso dentro do Delphi Win32. No nosso caso, optamos por utilizar web services desenvolvido em C#, desta maneira podíamos utilizar o conhecimento que já possuímos na área, e tanto o Portal em C# e o Delphi consomem essa tecnologia de uma maneira muito simples. Além disso, com web services podemos trabalhar a segurança, fazer a depuração e praticamente todas as linguagens suportam esta tecnologia.

Outro caso que participei foi o desenvolvimento de um sistema em PDA para restaurante, um sisteminha de Comanda eletrônica. O trabalho consistia em utilizar o banco já existente como fonte de dados, efetuar vários processos no PDA e o Sistema do restaurante deveria entender tudo como se tivesse partido dele mesmo. Imaginei que seria um trabalhão, até ver que todas as regras de movimentação estavam no banco, barbada !!! Foi só chamar as funções de abertura de mesa, venda de item, encerramento e correr pro abraço. Nesse caso a regra no banco foi fundamental para uma implementação rápida, segura e eficiente.

Bom, como quase todo mundo deve ter comentado em seus tópicos, analise bem sua situação, seu ambiente, a expertise de sua equipe e para onde seu sistema tende a evoluir, e ai faça sua escolha. Eu defendo muito a regra em web services, sei que em alguns casos ela pode até não ser a melhor opção, mas se a tendência é nossas aplicações desktop realmente evoluírem para um novo tipo de aplicações web (RIA, Web2.0 ), pelo menos os web services ainda poderão ser utilizados da mesma forma como são hoje.