Camadas de serviços e repositórios

Question

Eu tenho usado frameworks MVC por um curto tempo e agora eu realmente gosto de como as preocupações são separados. Eu tenho em um mau hábito de deixar os controladores de fazer um pouco de trabalho. Então, eu realmente estou procurando alguns conselhos.

Quando eu comecei usando MVC eu muitas vezes tive o controlador fazendo manipulação sobre os modelos após o trabalho de banco de dados tinha sido feito. Eu sabia que isso era ruim tão comovido que o trabalho nos modelos. No entanto, eu não estou feliz com isso como eu quero que meus modelos a ser muito aprender.

Eu fiz um pouco de leitura e eu ver que as pessoas estão mantendo seus controladores e modelos inclinar-se por ter uma camada de serviço, que eu gosto de olhar.

Eu só estou tentando entender como uma camada de serviço e repositório deve todos juntos trabalho. Aqui estão as minhas hipóteses, você pode por favor deixe-me saber se isso é uma boa maneira de trabalhar?

1. O controlador pode chamar o repositório diretamente se há necessidades de manipulação a ser feito sobre os dados e, como tal camada de serviço não precisa se envolver
2. Uma vez que todas as necessidades de trabalho a ser feito para dados (lógica de negócio), então isso deve ser feito na camada de serviço e o controlador irá fazer uma simples chamada para a camada de serviço como e quando necessário
3. Uma vez que o serviço tem feito isso de lógica de negócios que irá, em seguida, usar o repositório conforme necessário (se as necessidades de dados a ser persistentes).
4. Models, idealmente, deve ser mantido magra, idealmente atos como nada mais do que DTOs
5. Validação de dados será feito dentro dos modelos (usando atributos de validação Monorail). Eu aprecio nem um sequer gostos poluentes seus modelos com muitos atributos, mas isso é uma discussão diferente. I como o benefício de validação de MonoRail atributos para a validação jQuery automática na interface do usuário.

Eu estou tentando transformar todo o meu código em torno do princípio da responsabilidade individual, portanto, tentar resolver minhas práticas de codificação.

Graças

Answer 1

Em primeiro lugar, não existe um conjunto de regras que vai funcionar em todas as situações. Como você modelo que você está aplicativo depende muito do tipo e da complexidade do projeto. Dito isto, aqui estão algumas idéias:

1. errado Nada com chamando o repositório de um controlador. Apenas certifique-se o controlador não contém lógica de negócios.
2. O serviço cuida de (algumas) lógica de negócios e utiliza outros serviços para fazê-lo. O repositório é um tipo de serviço, não há nada de errado com chamando-o de um serviço.
3. O modelo deve conter lógica de negócios, na verdade, você deve sempre tentar colocá-lo no modelo de primeira. Se você precisa de dados externos para executar essa lógica de negócios (de outro modelo ou do repositório), então você deve criar um serviço.
4. errado Nada com a validação dos modelos. Usando atributos ou não é uma questão de gosto (se você gosta dele, então é bom). Mova o exterior validação do modelo se ficar muito complexo (criar um conjunto externo de regras).

O mais importante, fazer o que se sente bem (que é geralmente a resposta certa).

Answer 2

Este vídeo dá grande insights sobre como organizar sua solução asp.net MVC e separação tratar de preocupações, e melhor capacidade de teste. Esperemos que isso vai ajudar alguém também. Eu aprendi algumas coisas boas dele.

Answer 3

Ian Cooper acaba de escrever um post chamado O Controlador gordo em apenas este assunto.