Arquitetura da aplicação
Oi!
Atualmente trabalho em um projeto que criei a camada de interface (windows application), a camada de negócios (uma pasta chamada BLL dentro de um projeto Class Library) e a camada de persistência (uma pasta chamada DAL dentro do mesmo projeto Class Library da pasta BLL).
Na DAL no momento que se tem é apenas persistência no banco de dados. Mas em alguns casos (pensando em adotar um padrão) uma aplicação tem a necessidade de trabalhar na sua infra com arquivos, seja texto, xml... ou outras coisas do tipo.
Inicialmente estava pensando em criar uma pasta chamada Infra na Class Library, e nessa sim, ter uma outra para DAL, outra pasta para Arquivos, outra para XML, conforme a necssidade de infra do projeto.
O que vocês acham a respeito, melhor estruturar dessa forma para organizar as coisas e adotar assim como um padrão, ou fazer a infra dessas classes dentro da pasta DAL não tem nenhum problema?
Outra coisa que notei em um projeto que vi recentemente, o desenvolvedor criou um projeto Class Library em uma solution, e depois criou a camada de interface em outra solution, e fez referência para o arquivo compilado na pasta bin\Release.
Geralmente eu crio os projetos dentro de uma solution mesmo, e faço referências de um projeto para outro apontando o próprio projeto.
Para questões de distribuição da aplicação (independente de windows, web, mobile), qual seria melhor? O que eu faço hoje, ou o que eu notei no outro projeto?
OBS: Faço esta pergunta pois, no projeto feito por outra pessoa ao ter estruturado dessa forma, deu a entender que ele poderia compilar o projeto de Class Library caso houvesse alguma alteração na classe, e distribuiria somente o arquivo dll, sem ter que recompilar o projeto com a camada de interface (exemplo windows application). Estou certo nesse pensamento?
Atualmente trabalho em um projeto que criei a camada de interface (windows application), a camada de negócios (uma pasta chamada BLL dentro de um projeto Class Library) e a camada de persistência (uma pasta chamada DAL dentro do mesmo projeto Class Library da pasta BLL).
Na DAL no momento que se tem é apenas persistência no banco de dados. Mas em alguns casos (pensando em adotar um padrão) uma aplicação tem a necessidade de trabalhar na sua infra com arquivos, seja texto, xml... ou outras coisas do tipo.
Inicialmente estava pensando em criar uma pasta chamada Infra na Class Library, e nessa sim, ter uma outra para DAL, outra pasta para Arquivos, outra para XML, conforme a necssidade de infra do projeto.
O que vocês acham a respeito, melhor estruturar dessa forma para organizar as coisas e adotar assim como um padrão, ou fazer a infra dessas classes dentro da pasta DAL não tem nenhum problema?
Outra coisa que notei em um projeto que vi recentemente, o desenvolvedor criou um projeto Class Library em uma solution, e depois criou a camada de interface em outra solution, e fez referência para o arquivo compilado na pasta bin\Release.
Geralmente eu crio os projetos dentro de uma solution mesmo, e faço referências de um projeto para outro apontando o próprio projeto.
Para questões de distribuição da aplicação (independente de windows, web, mobile), qual seria melhor? O que eu faço hoje, ou o que eu notei no outro projeto?
OBS: Faço esta pergunta pois, no projeto feito por outra pessoa ao ter estruturado dessa forma, deu a entender que ele poderia compilar o projeto de Class Library caso houvesse alguma alteração na classe, e distribuiria somente o arquivo dll, sem ter que recompilar o projeto com a camada de interface (exemplo windows application). Estou certo nesse pensamento?
Carlos Nogueira
Curtidas 0
Respostas
Fabio Mans
29/12/2009
Olá Carlos eu acho interessante fazer como você está pensando, separe as responsabilidades para cada camada, não misture Infra com DAL.
Sobre sua segunda pergunto caso pense em utilizar as camadas em outros projetos a melhor opção é criar separado e utilizar o Assembly, você está certo no seu pensamento. Uma outra opção que vejo com frequência em pequenos projetos Web é colocar as classes na App_Code, também não vejo problema, pois facilita o trabalho. Mas tudo o que você disse está correto, e não existe um padrão, mas o que eu particularmente gosto e utilizo é criar o Class Library.
Espero ter ajudado.
Fabio
==============================================================================
Oi!
Atualmente trabalho em um projeto que criei a camada de interface (windows application), a camada de negócios (uma pasta chamada BLL dentro de um projeto Class Library) e a camada de persistência (uma pasta chamada DAL dentro do mesmo projeto Class Library da pasta BLL).
Na DAL no momento que se tem é apenas persistência no banco de dados. Mas em alguns casos (pensando em adotar um padrão) uma aplicação tem a necessidade de trabalhar na sua infra com arquivos, seja texto, xml... ou outras coisas do tipo.
Inicialmente estava pensando em criar uma pasta chamada Infra na Class Library, e nessa sim, ter uma outra para DAL, outra pasta para Arquivos, outra para XML, conforme a necssidade de infra do projeto.
O que vocês acham a respeito, melhor estruturar dessa forma para organizar as coisas e adotar assim como um padrão, ou fazer a infra dessas classes dentro da pasta DAL não tem nenhum problema?
Outra coisa que notei em um projeto que vi recentemente, o desenvolvedor criou um projeto Class Library em uma solution, e depois criou a camada de interface em outra solution, e fez referência para o arquivo compilado na pasta bin\Release.
Geralmente eu crio os projetos dentro de uma solution mesmo, e faço referências de um projeto para outro apontando o próprio projeto.
Para questões de distribuição da aplicação (independente de windows, web, mobile), qual seria melhor? O que eu faço hoje, ou o que eu notei no outro projeto?
OBS: Faço esta pergunta pois, no projeto feito por outra pessoa ao ter estruturado dessa forma, deu a entender que ele poderia compilar o projeto de Class Library caso houvesse alguma alteração na classe, e distribuiria somente o arquivo dll, sem ter que recompilar o projeto com a camada de interface (exemplo windows application). Estou certo nesse pensamento?
Atualmente trabalho em um projeto que criei a camada de interface (windows application), a camada de negócios (uma pasta chamada BLL dentro de um projeto Class Library) e a camada de persistência (uma pasta chamada DAL dentro do mesmo projeto Class Library da pasta BLL).
Na DAL no momento que se tem é apenas persistência no banco de dados. Mas em alguns casos (pensando em adotar um padrão) uma aplicação tem a necessidade de trabalhar na sua infra com arquivos, seja texto, xml... ou outras coisas do tipo.
Inicialmente estava pensando em criar uma pasta chamada Infra na Class Library, e nessa sim, ter uma outra para DAL, outra pasta para Arquivos, outra para XML, conforme a necssidade de infra do projeto.
O que vocês acham a respeito, melhor estruturar dessa forma para organizar as coisas e adotar assim como um padrão, ou fazer a infra dessas classes dentro da pasta DAL não tem nenhum problema?
Outra coisa que notei em um projeto que vi recentemente, o desenvolvedor criou um projeto Class Library em uma solution, e depois criou a camada de interface em outra solution, e fez referência para o arquivo compilado na pasta bin\Release.
Geralmente eu crio os projetos dentro de uma solution mesmo, e faço referências de um projeto para outro apontando o próprio projeto.
Para questões de distribuição da aplicação (independente de windows, web, mobile), qual seria melhor? O que eu faço hoje, ou o que eu notei no outro projeto?
OBS: Faço esta pergunta pois, no projeto feito por outra pessoa ao ter estruturado dessa forma, deu a entender que ele poderia compilar o projeto de Class Library caso houvesse alguma alteração na classe, e distribuiria somente o arquivo dll, sem ter que recompilar o projeto com a camada de interface (exemplo windows application). Estou certo nesse pensamento?
GOSTEI 0
Carlos Nogueira
29/12/2009
Olá Fabio!
Muito obrigado pelas dicas. Só me restou algumas dúvidas.
Quanto ao que você mencionou de não misturar infra com DAL, o que seria? É o caso que mencionei de ter uma pasta DAL e lá estar fazendo todas as situações até mesmo de trabalhar com arquivos texto, xml e etc... desta forma, misturando o conceito de DAL (camada de acesso) com demais situações que podem acontecer na infra?
Então, sobre o segundo item que você mencionou, até o momento para ser sincero, ainda não participei de um projeto que utiliza a mesma regra de negócio (mesma class library/assembly). Eu entendi quando você mencionou que não existe um padrão, é que estou pesquisando a melhor forma de fazer isso (ou se já é pelo que estou fazendo) para que, se possível, adotar como um padrão para equipe, principalmente para aqueles que ainda vão trabalhar com .NET, entende?
Então caso alguém questione essa questão da distribuição, precisaria ter uma justificativa boa por ter adotado daquela forma.
Muito obrigado pelas dicas. Só me restou algumas dúvidas.
Quanto ao que você mencionou de não misturar infra com DAL, o que seria? É o caso que mencionei de ter uma pasta DAL e lá estar fazendo todas as situações até mesmo de trabalhar com arquivos texto, xml e etc... desta forma, misturando o conceito de DAL (camada de acesso) com demais situações que podem acontecer na infra?
Então, sobre o segundo item que você mencionou, até o momento para ser sincero, ainda não participei de um projeto que utiliza a mesma regra de negócio (mesma class library/assembly). Eu entendi quando você mencionou que não existe um padrão, é que estou pesquisando a melhor forma de fazer isso (ou se já é pelo que estou fazendo) para que, se possível, adotar como um padrão para equipe, principalmente para aqueles que ainda vão trabalhar com .NET, entende?
Então caso alguém questione essa questão da distribuição, precisaria ter uma justificativa boa por ter adotado daquela forma.
GOSTEI 0
Fabio Mans
29/12/2009
Olá, sobre a DAL nesta camada eu utilizo somente para CRUD, nada mais. (Utilize um SqlHelper).
Sobre a BLL eu utilizo para consistir inclusão e exclusão. Se você acompanhar o Fórum de Arquitetura, verá que este é um tema polêmico, inclusive nas nomenclaturas e o importante é definir um padrão que a equipe compreenda, até hoje em todos os projetos que eu trabalhei eu vejo que cada empresa faz de um jeito.
Eu particularmente gosta de fazer o seguinte.
VO - Classes com os atributos e propriedades.
DAL - Inclusão, Exclusão, Alteração e leitura, utilizo List<T> para retornar. (Estou estudando Entity)
BLL - Faço a validação, veja o exemplo abaixo.
Interface - Web, Windows e etc.
Exemplo de BLL
public class PedidoCotacaoRetornadoBLL
{
public int IncluirPedidoCotacaoRetornado(PedidoCotacaoRetornadoVO pedidoCotacaoRetornadoVo)
{
if (pedidoCotacaoRetornadoVo.CodigoPedidoCotacao == "0")
throw new Exception("Codigo pedido cotação inválido"); if(pedidoCotacaoRetornadoVo.CodigoFornecedor == "0")
throw new Exception("Codigo do fornecedor inválido"); if(!ValidaData(pedidoCotacaoRetornadoVo.DataResposta.ToString()))
throw new Exception("Data de resposta inválida"); if (pedidoCotacaoRetornadoVo.ValidadeResposta.Trim().Length == 0)
throw new Exception("Informe a validade da resposta."); if (pedidoCotacaoRetornadoVo.Frete.Trim().Length == 0)
throw new Exception("Informe o frete");
//Se tudo estiver ok, chama a rotina de gravação
PedidoCotacaoRetornadoDAO PedidoCotacaoRetornadoDao = new PedidoCotacaoRetornadoDAO();
int solicitacao = PedidoCotacaoRetornadoDao.IncluirPedidoCotacaoRetornado(pedidoCotacaoRetornadoVo);
return solicitacao; } private bool ValidaData(string strDate)
{
try
{
DateTime.Parse(strDate);
return true;
}
catch (FormatException e)
{
return false;
}
} } Tem projetos que crio Class Library outros mais simples deixo as classes na App_Code mesmo. http://social.msdn.microsoft.com/Forums/pt-BR/arquiteturapt/threads Espero ter ajudado. =========================================================== Olá Fabio!
Muito obrigado pelas dicas. Só me restou algumas dúvidas.
Quanto ao que você mencionou de não misturar infra com DAL, o que seria? É o caso que mencionei de ter uma pasta DAL e lá estar fazendo todas as situações até mesmo de trabalhar com arquivos texto, xml e etc... desta forma, misturando o conceito de DAL (camada de acesso) com demais situações que podem acontecer na infra?
Então, sobre o segundo item que você mencionou, até o momento para ser sincero, ainda não participei de um projeto que utiliza a mesma regra de negócio (mesma class library/assembly). Eu entendi quando você mencionou que não existe um padrão, é que estou pesquisando a melhor forma de fazer isso (ou se já é pelo que estou fazendo) para que, se possível, adotar como um padrão para equipe, principalmente para aqueles que ainda vão trabalhar com .NET, entende?
Então caso alguém questione essa questão da distribuição, precisaria ter uma justificativa boa por ter adotado daquela forma.
{
public int IncluirPedidoCotacaoRetornado(PedidoCotacaoRetornadoVO pedidoCotacaoRetornadoVo)
{
if (pedidoCotacaoRetornadoVo.CodigoPedidoCotacao == "0")
throw new Exception("Codigo pedido cotação inválido"); if(pedidoCotacaoRetornadoVo.CodigoFornecedor == "0")
throw new Exception("Codigo do fornecedor inválido"); if(!ValidaData(pedidoCotacaoRetornadoVo.DataResposta.ToString()))
throw new Exception("Data de resposta inválida"); if (pedidoCotacaoRetornadoVo.ValidadeResposta.Trim().Length == 0)
throw new Exception("Informe a validade da resposta."); if (pedidoCotacaoRetornadoVo.Frete.Trim().Length == 0)
throw new Exception("Informe o frete");
//Se tudo estiver ok, chama a rotina de gravação
PedidoCotacaoRetornadoDAO PedidoCotacaoRetornadoDao = new PedidoCotacaoRetornadoDAO();
int solicitacao = PedidoCotacaoRetornadoDao.IncluirPedidoCotacaoRetornado(pedidoCotacaoRetornadoVo);
return solicitacao; } private bool ValidaData(string strDate)
{
try
{
DateTime.Parse(strDate);
return true;
}
catch (FormatException e)
{
return false;
}
} } Tem projetos que crio Class Library outros mais simples deixo as classes na App_Code mesmo. http://social.msdn.microsoft.com/Forums/pt-BR/arquiteturapt/threads Espero ter ajudado. =========================================================== Olá Fabio!
Muito obrigado pelas dicas. Só me restou algumas dúvidas.
Quanto ao que você mencionou de não misturar infra com DAL, o que seria? É o caso que mencionei de ter uma pasta DAL e lá estar fazendo todas as situações até mesmo de trabalhar com arquivos texto, xml e etc... desta forma, misturando o conceito de DAL (camada de acesso) com demais situações que podem acontecer na infra?
Então, sobre o segundo item que você mencionou, até o momento para ser sincero, ainda não participei de um projeto que utiliza a mesma regra de negócio (mesma class library/assembly). Eu entendi quando você mencionou que não existe um padrão, é que estou pesquisando a melhor forma de fazer isso (ou se já é pelo que estou fazendo) para que, se possível, adotar como um padrão para equipe, principalmente para aqueles que ainda vão trabalhar com .NET, entende?
Então caso alguém questione essa questão da distribuição, precisaria ter uma justificativa boa por ter adotado daquela forma.
GOSTEI 0
Carlos Nogueira
29/12/2009
Entendo.
E neste mesmo modelo que você passou, se você precisar gerar um arquivo XML para enviar para um outro sistema, a escrita deste arquivo ou as regras que contém nele para manipular (nome, local que será armazenado,...) você delegaria essa responsabilidade para PedidoCotacaoRetornadoBLL ou para alguma outra classe que trate de arquivo XML?
E neste mesmo modelo que você passou, se você precisar gerar um arquivo XML para enviar para um outro sistema, a escrita deste arquivo ou as regras que contém nele para manipular (nome, local que será armazenado,...) você delegaria essa responsabilidade para PedidoCotacaoRetornadoBLL ou para alguma outra classe que trate de arquivo XML?
GOSTEI 0
Fabio Mans
29/12/2009
Para outra classe, porque a responsabilidade da BLL é só validar, não trabalhar com XML.
Fabio
GOSTEI 0
Fabio Mans
29/12/2009
Posso ajudar em mais alguma dúvida?
GOSTEI 0
Carlos Nogueira
29/12/2009
Tranquilo Fabio, acho que com isso, já clareou um pouco como devo padronizar a arquitetura dos projetos.
Obrigado pela sua atenção e me desculpe pelo atraso!
Obrigado pela sua atenção e me desculpe pelo atraso!
GOSTEI 0