Estruturação uma solução winforms C #

Question

Então, eu estou reorganizando uma solução winforms C # para ajudar a separar e torná-lo mais limpo e organizado. A solução rastreia um pequeno ordens de negócios, etc. .

Eu quebrei os projectos até agora em

App.View - todos GUI código relacionado
App.Data - estruturas de dados apenas e interfaces. Nenhum outro código de implementação
App.BusinessLogic - todo o código lógica de negócios que não tem referências GUI

Eu tenho algumas classes que eu não consigo descobrir onde eles pertencem. Por favor, deixe-me saber seus pensamentos que projetam cada classe deve ir ou se houver outro projeto que deve ser criada para isso.

1. A Classe que as preferências recupera usuário de um banco de dados
2. Uma classe que recupera dados estáticos do nosso servidor de dados estáticos e retorna conjuntos de resultados de dados.
3. Uma classe que derruba direitos de utilização
4. A classe de modelo que armazena uma tabela hash de ordens
5. classe A que e-mails fora mensagens sobre uma ação do usuário

Answer 1

Na verdade, eu acho que você tem coisas um pouco fora de uma arquitetura em camadas tradicional. Normalmente, os modelos de seus dados que o aplicativo funciona no seriam mantidos em uma camada de negócios, juntamente com o código para operar sobre eles. Sua camada de dados teria ambos os modelos de dados do seu framework de persistência eo código para interagir com esse quadro. Acho que isso pode ser a fonte da confusão entre os locais sugeridos de suas classes e sua reação a ele com base em seus comentários.

A partir dessa perspectiva nada que recupera ou traz necessariamente ser localizado em sua camada de dados - é o acesso a dados no armazenamento persistente. O que ele recupera são eventualmente convertida em camada de objetos de negócios que a sua lógica de negócio opera. As coisas são são modelos conceituais - como uma mesa de ordens - ou acções comerciais pertencem na camada de negócios. Concordo com @Adron com, talvez, a mesma confusão sobre onde (3) vai dependendo do que ele realmente é.

Mais especificamente:

1. Preferências do usuário são negócios objetos, a coisa que recupera eles é um objeto da camada de dados.
2. Os dados estática mapeia para um negócio objeto (tabela ou exibição ou algo assim), a coisa que acessa o externo servidor é um objeto da camada de dados.
3. O direito de usuário é um objeto de negócios, a coisa que recupera é objeto da camada de dados.
4. Uma tabela da Ordem é um objeto de negócios
5. Emailing é uma atividade de negócio, por isso a única coisa que mails pessoas é um objeto de negócios

[EDIT] Meu generalizada 3-Tier Architecture for (simples) aplicações web

DataAccessLayer

Isto incluiria meus TableAdapters e DataTables e fábricas que transformam fileiras de minhas tabelas de dados em objetos de negócios em projetos pré-LINQ rigidez. Usando LINQ isso incluiria meus entidades DataContext e designer LINQ gerado.

BusinessLayer

Isto inclui qualquer lógica de negócios, incluindo a validação e segurança. Na pré-LINQ estes seriam os meus objetos de negócios e quaisquer outras classes que implementam a lógica do aplicativo. Usando LINQ estas são as implementações de classe parcial do meu entidades LINQ para implementar a segurança e validação junto com quaisquer outras classes para implementar a lógica de negócios.

Apresentação

Estes são os meus formulários web - basicamente, a interface do usuário do aplicativo. Eu faço incluir alguns dos lógica de validação nas formas como uma otimização, embora estes também são validados no BL. Isto também inclui quaisquer controles de usuário.

Nota: Esta é a estrutura lógica. A estrutura do projeto geral espelhos isso, mas há alguns casos, como conexões com serviços web, que podem ser diretamente incluídos no projeto web, embora logicamente os componentes são realmente no BL / DAL.

Nota: eu provavelmente vou estar se movendo para MVC mais de 3-Tier uma vez ASP.NET MVC está em produção. Já fiz alguns projetos pessoais em Ruby / Rails e eu realmente gosto do paradigma MVC para aplicações web.

Answer 2

Você especificou que App.Data deve conter apenas as estruturas de dados e interfaces, nenhum código de implementação, o que é bom se você quiser fazer isso, mas que te deixa com nenhum lugar para colocar o seu código de acesso de banco de dados, exceto em sua App.BusinessLogic montagem.

Talvez você realmente precisa para mudar o nome App.Data para App.Model (ou algo similar), e ter um novo App.DataAccess montagem que fala com o banco de dados (talvez implementar um padrão Repository). Tendo feito isso, eu iria dividir as coisas como esta:

1. App.DataAccess
2. App.DataAccess
3. App.DataAccess
4. App.Model
5. App.BusinessLogic

Answer 3

Eu provavelmente iria com

1. Os dados
2. Os dados
3. Os dados, embora eu não sou inteiramente certo o que a classe está fazendo
4. Os dados
5. BusinessLogic

Answer 4

1. -> App.Data
2. -> App.Data
3. -> App.BusinessLogic ou App.Data -. Não tenho certeza exatamente o que isso significa
4. -> App.BusinessLogic
5. -> App.BusinessLogic