Como você arquitetaria um aplicativo de desktop em C# 3.0

Question

Eu criei um aplicativo de desktop simples em C# 3.0 para aprender um pouco de C#, wpf e .Net 3.5.Meu aplicativo essencialmente lê dados de um arquivo csv e os armazena em um banco de dados SQL Server CE.Eu uso o sqlmetal para gerar o código ORM do banco de dados.Minha primeira iteração deste aplicativo é feia pra caramba e estou refatorando-o.

O que me leva à minha pergunta.Como você arquitetaria um aplicativo de banco de dados de desktop em C#?quais são as melhores práticas?

Você cria uma camada de abstração de banco de dados (DAL) que usa o código gerado pelo sqlmetal?Ou o código gerado é uma abstração suficiente?

Se você usar o padrão DAL, você o tornará um singleton ou um membro estático?Você usa o padrão View-Model-ModelView com o padrão DAL?

Peço desculpas se esta parece uma questão muito aberta, mas tenho pensado muito sobre isso recentemente.Vejo muitos exemplos de como arquitetar um aplicativo corporativo de n camadas em C#, mas não tantos exemplos de arquitetura de aplicativos de desktop independentes.

Answer 1

Eu começaria com o Orientação de aplicação composta para WPF (tosse PRISMA tosse) da equipe de P&P da Microsoft.Com o download vem um ótimo aplicativo de referência que é o ponto de partida para a maior parte do meu desenvolvimento WPF hoje.

O Equipe DotNetRocks acabei de entrevistar Glenn Block e Brian Noyes sobre isso se você estiver interessado em ouvir mais deles.

Melhor ainda, o Prism não é tão pesado quanto o CAB, se você estiver familiarizado com isso desde a época do WinForms.

Answer 2

A resposta é “depende”, como sempre.

Algumas coisas para pensar:Você pode querer transformar esse aplicativo cliente gordo em um aplicativo da web (por exemplo) em algum momento.Nesse caso, você deve manter a separação entre a camada de negócios (e abaixo) e a apresentação.A maneira mais simples de fazer isso é garantir que todas as chamadas para a lógica de negócios passem por algum tipo de interface.Uma maneira mais complexa é implementar uma configuração MVC completa.

Outra coisa que você pode considerar é tornar a camada de acesso a dados independente da lógica de negócios e da interface do usuário.Com isso quero dizer que todas as chamadas da lógica de negócios para o DAL devem ser genéricas "obtenha esses dados" em vez de "obtenha esses dados do SQL" ou, pior ainda, "execute esta instrução SQL".Dessa forma, você pode substituir seu DAL por um que acesse um banco de dados diferente, arquivos XML ou até mesmo algo nojento como arquivos simples.

Em suma, separação de preocupações.Isso permite que você cresça no futuro adicionando uma UI diferente, segmentando todas as três áreas em seu próprio nível ou alterando a tecnologia relevante.

Answer 3

Antes de arquitetar qualquer coisa, você deve definir os requisitos para seu aplicativo.
É um erro comum de desenvolvedores iniciantes - começar a escrever código antes de pensar em como ele funcionaria.Meu conselho será tentar descrever alguns recursos do seu aplicativo.Isso o ajudará a sentir como deve ser implementado.

Quanto aos recursos de aprendizagem úteis, recomendo fortemente que você dê uma olhada em CompostoWPF é um projeto projetado especificamente para ensinar aos desenvolvedores as melhores práticas de desenvolvimento de aplicativos para desktop.

Answer 4

Eu começaria com Jeremy Miller Construa seu próprio táxi Series.

Fui um dos primeiros a adotar o CAB.Aprendi muito investigando essa tecnologia e lendo todos os blogs .NET sobre arquitetura de aplicativos.

Mas recentemente tive a oportunidade de iniciar um novo projeto e, em vez de usar CAB, optei pelo StructureMap e NHibernate e peguei emprestados alguns dos padrões que Jeremy usa (em particular, sua maneira de lidar com a agregação de eventos).O resultado foi uma estrutura realmente simplificada e feita à mão que faz tudo que preciso e adoro trabalhar com ela.

Quanto aos detalhes da sua pergunta:Eu uso um repositório para acesso a dados.Inicialmente escrevi algum código ADO.NET e usei leitores de dados e mapeei meus objetos.Mas isso envelheceu muito rápido, então peguei o NHibernate e fiquei muito satisfeito.Os repositórios usam NHibernate para acesso a dados, e minhas necessidades de acesso a dados são bastante simples neste aplicativo específico.

Eu tenho uma camada de serviço (exposta via WCF, canais Duplex) que utiliza os repositórios.Meu aplicativo é basicamente cliente-servidor com atualização em tempo real (e sei que sua pergunta era apenas sobre clientes, mas eu usaria as mesmas tecnologias e padrões).Ó

No lado do cliente, utilizo MVP com StructureMap para IoC e algumas estratégias de agregação de eventos muito simples para comunicações entre classes.Eu codifico para interfaces para quase tudo.A única outra coisa que fiz foi emprestar do CAB a ideia de um "espaço de trabalho" flexível para exibir visualizações dinamicamente.Eu escrevi minha própria interface Workspace e implementei meu próprio DeckWorkspace e TableWorkspace para uso em meu aplicativo (essas eram coisas realmente simples de escrever).

Muitas das minhas decisões nesta aplicação mais recente foram o resultado da experiência e da dor que senti ao usar outras estruturas e ferramentas.Tomei decisões diferentes desta vez.Talvez a única maneira de realmente entender como arquitetar um aplicativo seja sentir a dor de fazer algo errado de antemão.

Answer 5

Eu diria que sim, poderia facilmente ser estruturado para aplicações menores.Há uma curva de aprendizado para começar, mas honestamente, isso me ajudou a entender melhor o WPF do que tentar começar do zero.Depois de iniciar um projeto com CompositeWPF e iniciar outro projeto sem ele, me vi tentando duplicar recursos do CompositeWPF sozinho porque senti falta desses recursos!:)