ASP.NET MVC com camada de serviço de repositório e de camada, onde as interfaces de ser definido?

Question

Eu estou no processo de determinação de uma forma bastante simples arquitetura em camadas para um .NET MVC aplicação que possui um repositório de camada e a camada de serviço.Eu tenho encontrado alguns bastante clara e simples exemplos, nomeadamente www.asp.net, e algumas perguntas e respostas aqui, mas eu estou procurando por algo que é um pouco mais simples, adequado para aplicações de pequeno porte, mas que usa diferentes projetos, para passar a ideia.O exemplo que eu vinculada ao acima tem o repositório e o serviço como classes em Modelos de espaço de nomes.Que apenas não é suficiente para uma separação clara para mim ser capaz de mostrá-lo corretamente.

Eu tenho um projeto separado para o repositório que implementa a interface IRepository.Há um separarate projeto para o Serviço que implementa IService e leva um IRepository (constructor injection).O Serviço implementa IService.É o suficiente para, neste exemplo, o controlador de instanciar o serviço, sem a necessidade de um contêiner IoC ainda.Pense nisso como um passo intermediário para a compreensão de melhores práticas arquitetônicas, parte de uma sequência que constrói, progressivamente, para incluir a injeção de dependência e, possivelmente, mais camadas.

A questão é, onde devo definir IRepository e IService?Tanto o serviço de repositório e projetos precisam de referência-los, é claro.Parece claro, então, que eles devem ser definidos em um outro projeto referenciada por ambos o serviço de repositório e projetos.Se assim for, o que seria um bom convenção de nomenclatura de ser?Algo como XXXXContracts?

Da mesma forma, para os modelos de dados passados entre a apresentação, serviço de repositório e camadas, é aceitável ter um projeto separado chamado XXXXModels referenciado por todas as camadas?Eu entendo que em alguns casos os modelos passados entre o serviço e a camada de repositório podem diferir dos passados entre a camada de serviço e a camada de apresentação, mas o princípio é o mesmo.

Eu tenho encontrado respostas para perguntas semelhantes aqui, mas eles tendem a envolver uma arquitetura mais complicada do que o que descrevi aqui.Eu estou olhando para alcançar uma verdade simples e limpo ilustração das duas camadas, que pode ser visto como um passo ou dois acima de referência a camada de dados e ter a lógica de negócios na controladores, isso é tudo.Eu sei que há uma forte e argumento válido para ir direto para o full-blown melhores práticas, mas nem todos são adequados para fazer que saltar em um ir.

Answer 1

Introdução

Isso é algo que eu perguntei a mim mesmo também.Uma questão que eu sempre tenho é semelhante ao seu;

o que seria uma boa convenção de nomenclatura de ser?

Como devo nome de coisas?Eles deveriam ir em pastas ou projetos?

Depois de pesquisar em torno eu suspeito que a resposta é que isso realmente não importa.O que é importante é que a solução de alguns sensível arquitetura e tentar seguir as boas práticas, tais como SÓLIDOS.

Meu ASP.NET MVC heróis neste tópico são Jeffrey Palermo, Steve Smith e Jimmy Bogard.

Cebola Arquitetura

Jeffrey Palermo descreve uma combinação de idéias antigas, mas reúne e dá-lo visualmente estimulante nome de Cebola Arquitetura (uma leitura recomendada).Jeffrey mostra uma boa abordagem para o problema de onde colocar as coisas.Ele explica que no centro (ou superior) de sua aplicação, você tem o seu Núcleo.Esta camada é onde você deve colocar tais como interfaces IRepository e IService.

Quase todas as suas interfaces deve ir no core e de tudo o resto (outros projetos) podem referência o núcleo.Desta forma, tudo o que conhece a estrutura do esqueleto do aplicativo sem conhecer os detalhes de implementação.

Tente fazer sua camada UI de referência tão pouco quanto possível (dentro da razão).Em uma de minhas aplicações minha INTERFACE do usuário (MVC) camada de referências Núcleo.Tudo o que precisa é injetado com Injeção De Dependência.

Steve Smith discute Cebola Arquitetura e idéias semelhantes com manifestações em MVC Solução de Melhores Práticas:Uma solução para a solução do problema

A minha solução

Na minha MVC soluções de eu ter uma típica estrutura como esta:

• MyProject.Núcleo
• MyProject.Domínio
• MyProject.DependencyInjection
• MyProject.Infra-estrutura
• MyProject.Web
• MyProject.Testes

O Núcleo contém meu interfaces.É normalmente dividido em pastas como a de Serviços, Modelos de Domínio, Repositórios e assim por diante.

O Domínio camada de referências apenas o núcleo e contém a minha implementação.Ele fornece um monte de classes concretas para o domínio da abstração no núcleo.Ele lida com um monte de lógica de negócios, processamento, manipulação de comando, gerenciador de classes, de concreto implementações de serviço e assim por diante.Eu considero bastante interno-camada e assim ele faz referência tão pouco quanto possível.

O DependencyInjection camada contém o meu escolhido DI pacote/framework e detalhes de implementação.Eu considero que é uma camada exterior;semelhante a INTERFACE do usuário ou de Infra-estrutura e por isso é ok se faz referência a um monte.Não é necessário para esta camada a ser um projeto separado e muitas pessoas vão dizer-lhe para não fazer isso.Está tudo ok;fazer o que funciona para a complexidade do seu projeto.Eu gosto do meu DI para ser sua própria coisa.A coisa boa sobre ele ser assim tão diferente é que eu poderia substituir o DI-quadro com um diferente e que tudo ficaria bem.Sem camadas referência a DI projeto.

O Infra-estrutura camada contém informações sobre o registro em log, e-mail e acesso a dados.Ele irá conter o meu ORM de escolha.Não é da lógica de negócios coisas e não UI coisas.É a estrada de ferro de minha solução para fazer as coisas.É na camada exterior, mas é apenas referencia o Núcleo.

O Web camada é o meu projeto MVC e apenas referências do Núcleo.

Complexidade e pensamento final

Eu tenho encontrado respostas para perguntas semelhantes aqui, mas eles tendem a envolver uma arquitetura mais complicada do que o que descrevi aqui

É um bom ponto.É importante manter em mente a complexidade do seu problema.Mas não se intimide pela boa solução de práticas.A minha solução e a Cebola Arquitetura não são, necessariamente, muito complexo e realmente não aumentarão a sua solução.Eles apenas manter as coisas separadas.

No Evolutiva Da Estrutura Do Projeto, Jimmy Bogard fala sobre coisas a ser mais complexo.Se o que eu disse parece muito complexo, siga Jimmy, conselhos e colocar tudo isso em um projeto (sua INTERFACE de camada).Isso é ok, desde que ele se adapta a você.

Lembre-se de levar a minha solução apenas como uma ideia - algo a se considerar;a minha abordagem é uma tentativa para seguir o sábio conselho do melhor, mas eu tenho certeza que eu tenho só conseguiu tanto;Eu posso (e deve) melhorar.