Organização GUI, BLL, DAL em um projeto

Estou lendo sobre as camadas do aplicativo e quero usar esse design no meu próximo projeto (c #, .Net). Algumas perguntas:

1. A separação de camadas é feita através de namespaces? Project.BLL.Whatever, Project.DAL.Whatever

2. É mais apropriado separar por camadas e componentes (Project.BLL.Component1) ou por componentes e camadas (Project.Component1.BLL)

3. Para o meu DAL, essa camada é mais organizada usando classes diferentes? Se todas as chamadas ao banco de dados forem colocadas em uma única classe, não haverá organização. Seria melhor dividir isso com diferentes classes ou namespaces?

4. As classes DAL são tipicamente estáticas? Parece complicado instanciar um objeto DAL antes de chamar um de seus métodos a cada vez.

Qualquer outra dica para fazer as coisas da maneira correta com essas camadas seria apreciada.

1. Sim. E também montagens.
2. Eu separaria por camadas, depois componentes.
3. Sim. Existem diferentes abordagens para isso, mas eu teria um IDatabaseService (abstraindo as várias maneiras pelas quais o banco de dados é chamado - isso pode ser quase um mapeamento direto do ExecuteScalar / ExecuteNonQuery / ExecuteReader) e várias classes de acesso a dados que partição por tipo de dados. Por exemplo, você poderia ter uma classe UserDataAccess que tivesse métodos CRUD simples que criam / modificam / excluem objetos de usuário. Outra abordagem seria ter um objeto Usuário com o CRUD embutido.

4. Não. Isso dificulta muito o teste de unidade. Você deve usar a injeção de dependência para transmitir dependências ao construtor de cada classe de acesso a dados (como um IDatabaseService). Você passaria os objetos de acesso a dados para os objetos de negócios, assim:

   BusinessObject businessObject = novo BusinessObject (novo DataAccessObject (novo DatabaseService ())); businessObject.PerformOperation ();

Cada objeto de negócios pode precisar de vários objetos de acesso a dados. Seu código da GUI também usaria um ou mais objetos de negócios. Alguns objetos de negócios podem não precisar de nenhum objeto de acesso a dados, mas nunca devem usar o IDatabaseService diretamente.

Para as perguntas 1 e 2, siga as respostas de Mateus.

Passei muito tempo tentando descobrir a melhor maneira de estruturar o DAL dos aplicativos de desktop. E a melhor maneira realmente depende das necessidades do aplicativo. Em um dos meus aplicativos, desenvolvi uma classe DA para cada tabela de banco de dados, que se registrou com uma classe DataProvider central (ou seja, singleton) e lidou com o CRUD. Cada classe DA poderia então decidir se queria ou não armazenar em cache todos os dados da tabela na RAM (desempenho!) E / ou se precisava ativar as atualizações automáticas de clientes em outros clientes em execução em outros computadores (pense em vários usuários concorrência). Isso facilita a adição de novas classes DAL, pois tudo o que eles precisam fazer é estar em conformidade com a interface de registro.

Nem todo DAL precisa desse tipo de funcionalidade, mas aprendi que a abordagem em si (por exemplo, provedor de dados singleton e classes DAL simples com registro estático) facilitou muito minha vida quando comecei a adicionar novas classes.

Definitivamente, eu não recomendaria criar o CRUD em classes de nível superior, a menos que este seja um aplicativo muito simples. O DAL é uma abstração do armazenamento de dados. Se você decidir alterar seu armazenamento de dados em algum momento no futuro (mesmo que seja apenas para usar o MySQL em vez do MS SQL), ficará muito agradecido por isso. Além disso: os objetos BLL devem ser estruturados por seus relacionamentos de lógica de negócios. Os objetos DAL são estruturados pelos tipos de contêineres de armazenamento que eles representam. As diferenças podem ser dramáticas.

Você não fazer o seu aulas DAL estática. O que você ganha em velocidade de codificação perde muitas vezes em testabilidade e flexibilidade.