Design da camada de serviço

5

Estou desenvolvendo um site MVC em PHP e, pela primeira vez, gostaria de implementar uma camada de serviço. Eu tenho algumas considerações de projeto que eu gostaria de obter alguns conselhos sobre. O back-end não será de forma alguma um sistema corporativo de grande porte, por isso estou procurando manter as coisas relativamente simples, aproveitando ao mesmo tempo os benefícios de uma camada de serviço.

A ideia é que meus controladores interajam com os serviços, que por sua vez irão interagir com os DAOs. Minha principal questão é como meus serviços devem ser granulares. Estou familiarizado com o conceito de granularidade de serviço na SOA, mas nunca implementei isso na prática. Por exemplo, para lidar com o registro do usuário, devo ter uma RegistrationService da classe ou devo ter um UserService que contenha um método register juntamente com outros serviços relacionados ao usuário? A primeira abordagem significa que terei uma camada de serviço repleta de serviços pequenos ou detalhados, mas acho que isso é bom. O último parece dificultar a reutilização do serviço e resultar em grandes classes com muitos métodos.

Em vez disso, talvez eu deva combinar as duas abordagens para garantir que meus serviços possam ser reutilizados? Por exemplo, tenha um RegistrationService que interage com uma classe DAO. Então, eu poderia ter uma classe UserService com um método register . Este método interage com o RegistrationService de baixa granularidade. Dessa forma, o RegistrationService pode ser facilmente reutilizado para compor mais serviços de granulação grossa. Certamente há exemplos em que a reutilização seria mais provável; por exemplo, fazer um pedido precisaria usar / orquestrar muitos serviços diferentes. Eu acho que você poderia chamar isso de uma abordagem "em camadas", que eu já vi discutido antes. Poderia estruturar isso de maneira que minha camada de serviço não se torne uma bagunça?

Eu adoraria ouvir sua opinião sobre isso, se você tem outras sugestões, recomendações e experiências ou comentários sobre as ideias que apresentei acima. Obrigado antecipadamente.

    
por Andy0708 26.01.2013 / 16:50
fonte

2 respostas

4

Bem, acho que RegistrationService é mais revelador.

Pode-se facilmente especular sobre qual função pode ser encontrada lá, como registerUser() , ConfirmRegisteration() , ResetPassword() , ... etc. Para mim, a maioria parece cair logicamente em uma classe RegisterionService do que uma classe geral UserService .

Uma camada de serviço deve conter funções que operam em mais de uma Entidade, portanto, um UserService pode não ser logicamente o melhor lugar para tais operações.

    
por 28.01.2013 / 23:24
fonte
0

Atualmente, as implementações de frameworks PHP não usam a camada de serviço, todas as computações de banco de dados são armazenadas na camada Model (ou seja, Doctrine & Co). Se você deseja inserir uma camada de serviço entre seu modelo e os controladores, você deve pensar em "transações".

Esta camada permitirá que você coloque somente operações atômicas em sua camada de banco de dados (DAO) e as encadeie dentro de transações na camada de serviço. Isso faz ainda mais sentido Se o seu rdms suportar a reversão parcial da transação.

Essa camada se tornará o ponto em que as exceções técnicas (exceção de chave primária do banco de dados) se tornam exceções de negócios (não foi possível colocar a exceção de ordem).

Não sei como implementar isso de forma limpa com ORMs ...

    
por 28.01.2013 / 13:58
fonte