Estou usando o ASP.net MVC há cerca de dois anos e ainda estou aprendendo a melhor maneira de estruturar um aplicativo.

Eu queria jogar fora essas idéias que reuni e ver se elas são maneiras "aceitáveis" na comunidade para projetar aplicativos MVC.

Aqui está o meu layout básico:

Projeto DataAccess - Contém todas as classes de repositório, contextos de dados LINQ para SQL, filtros e objetos de negócios personalizados para repositórios db SQL não MS (que LINQ para SQL não cria). Os repositórios normalmente têm apenas CRUD básico para o objeto que estão gerenciando.

Projeto de Serviço - Contém classes de serviço que executam lógica de negócios. Eles recebem pedidos dos Controladores e informam aos repositórios o que fazer.

Projeto UI - Contém modelos de exibição e alguns wrappers em torno de coisas como o ConfigurationManager (para teste de unidade).

Projeto MVC principal - Contém controladores e visualizações, além de javascript e css.

Parece uma boa maneira de estruturar aplicativos ASP.NET MVC 2? Mais alguma ideia ou sugestão?

Os modelos de vista são usados para toda a saída para vistas e a entrada de vistas?

Estou seguindo o caminho de criar modelos de exibição para cada objeto de negócios que precisa exibir dados na exibição e torná-los classes básicas com um monte de propriedades que são todas strings. Isso torna muito fácil lidar com as visualizações. A camada de serviço precisa gerenciar as propriedades de mapeamento do modelo de exibição para o objeto de negócios. Isso é fonte de algumas das minhas confusões, porque a maioria dos exemplos que eu vi no MVC / MVC2 não usa um modelo de exibição, a menos que você precise de algo como uma caixa de combinação.

Se você usar a nova validação de modelo do MVC 2, validaria o objeto viewmodel e não precisaria se preocupar em colocar os atributos de validação nos objetos de negócios?

Como você faz o teste de unidade desse tipo de validação ou não devo testar se as mensagens de validação são retornadas?

Obrigado!