none
MVC - DataObjetct VS Model - Estrutura de Sistema RRS feed

  • Pergunta

  • ola pessoal

    tenho estudado MVC e razor, e hoje parei pra pensar na minha estrutura, porem, nao sei se é a correta

    nos exemplos que vejo, o Model seria praticamente os DataObjets da minha aplicacao, porem, eu tenho isso separado em diversas solucoes, onde a solution BusinessLayer tem os DataObjetc.
    A questao é, quando u crio uma view eu faco referencia direta a esta Solution.Classe, por exemplo, se eu tenho a classe PEssoa, eu faco na pagina desta forma

     

    @using BusinessLayer;
    @model PessoaDO
    
    @{
      ViewBag.Title = "Search";
      Layout = "~/Views/Shared/_Layout.cshtml";
    .....

     

    a questao é, estou fazendo da forma correta, como seria o "correto" nesses casos?

    teria que ter uma PessoaModel que herda a PessoaDO, seria isso?

    nesse ponto fiquei meio perdido

    bem, fica ai a duvida

    abs
    T+ pessoal

     


    Carlos Eduardo Barbosa Analista de Sistema Business Intelligence WEB Intelligence
    segunda-feira, 21 de março de 2011 22:22

Todas as Respostas

  • Você poderia passar uma amostra do código de PessoaDO e como você faz essa persistência?


    andresilva.net
    @andresilva_net
    terça-feira, 22 de março de 2011 00:37
  • Olá Carlos,

    Se a diretiva @using BusinessLayer permite que você acesse classes de (regra de) negócios na view, eu vejo um problema aí. Idealmente, a view deve ser responsável apenas por exibir dados. Chamadas a métodos de negócios na view não devem ser feitas.

    Mas, como o André colocou,  uma amostra do código ajudaria bastante.

    Espero ter ajudado


    Allan
    terça-feira, 22 de março de 2011 12:54
  • Vamos la, tentei simplificar e compliquei..rs

     

    Segue meu codigo, (removi a parte interna e deixei mais simples pra nao colocar um milhao de linhas aqui, mas da pra entender eu acho)

    --MEU DataObjetct (DO)
    namespace BusinessLayer
    {
      public class PessoaDO
      {
        [Required]
        [DataType(DataType.Currency)]
        [Display(Name = "Código")]
        public int ID { get; set; }
    
        [Required]
        [DataType(DataType.Text)]
        [Display(Name = "Nome")]
        public string Nome { get; set; }
    
    
        [Required]
        [DataType(DataType.Text)]
        [Display(Name = "Documento")]
        public string Documento { get; set; }
    
    
      }
    }
    --MEU DataAcess (DB)
    namespace DataAcessLayer
    {
      public class PessoaDB
      {
        public void Insert(PessoaDO pessoaDO) { 
    
        }
      }
    }
    --Meu WorkFlow(WF)
    --A ideia desse cara e fazer o meio de campo do DO e do DB, assim nao dando acesso direto na view
    namespace WorkflowLayer
    {
      public class PessoaWF
      {
        private PessoaDB pessoaDB = new PessoaDB();
    
        public PessoaDB PessoaDB
        {
          get { return pessoaDB; }
          set { pessoaDB = value; }
        }
    
        public void InsertDB(PessoaDO pessoaDO) {
          this.PessoaDB.Insert(pessoaDO);
        }
      }
    }
    --Controler
    --é aqui que fico a pensar o que fazer.
    
    

     

    no controler, tem que fazer o acesso ao WorkFlow, ele faz a integracao do com o DO e o DB. porem, ai fico pensando, nao posso dar acesso direto ao BussinesLayer, entao, pensei em toda classe do WorkFlow tem uma propriedade do Bussines, ate por que de qualquer forma eu tenho que passar um Bussines como parametro nos metodos, o que acham disso?

    qual outra sugestao voce me dão?

    é que preciso definir a estrutura pra comecar a montar de verdade os sistemas em MVC.

    obrigado a todos
    abs


    Carlos Eduardo Barbosa Analista de Sistema Business Intelligence WEB Intelligence
    terça-feira, 22 de março de 2011 14:40
  • O código do seu primeiro post está certo, utilizando PessoaDO como model.

    No controller deve ter um parâmetro do tipo PessoaDO para receber os dados da view, e utilizar o PessoaBO para fazer CRUD (Create, Retrieve, Update, Delete) do objeto PessoaDO.

    Pelo que eu entendi também no último post, o projeto ainda está em fase de modelagem e eu recomendo que você fuja do Model Anêmico que utiliza BO, DO, etc.


    andresilva.net
    @andresilva_net
    terça-feira, 22 de março de 2011 20:56
  • Andre

    voce teria um link explicando o BO, DO com mais detalhes, pra eu entender as principais diferenças!

    Entao meu model acabaria ficando desta forma

      public class PessoaModel
      {
        private PessoaDO pessoaDO = new PessoaDO();
    
        public PessoaDO PessoaDO
        {
          get { return pessoaDO; }
          set { pessoaDO = value; }
        }
      }
    

     

    obrigado


    Carlos Eduardo Barbosa
    Analista de Sistema
    Business Intelligence
    WEB Intelligence

    carlos.ed.b@hotmail.com

    @carlos_ed_b

    Mercúrio – Comunicação Digital

    quarta-feira, 23 de março de 2011 13:01
  • O que eu quis dizer é que utilizar DO (Data Object) e BO (Business Object), onde no DO ficam apenas as informações do model, e no BO as funcionalidades relacionadas a ele você está indo contra a ideia de orientação a objeto. Segundo a wikipedia: "Uma classe define o comportamento de seus objetos através de métodos e os estados possíveis destes objetos através de atributos. Em outros termos, uma classe descreve os serviços providos por seus objetos e quais informações eles podem armazenar.". DOs e BOs são utilizados em Java devido a determinadas condições de EJB. Mas na maioria dos projetos, como ASP.NET MVC, não há a necessidade de utilizar dessa forma.

    Eu também já cheguei a utilizar DO e BO, então fica apenas uma sugestão para mudar de prática.

    Nós utilizamos aqui NHibernate com Castle (ActiveRecord), um exemplo de model daqui é assim:

     

    [ActiveRecord(Table = "pessoas", Lazy = true, DynamicUpdate = true)]
    public class Pessoa : ActiveRecordLinqBase<Pessoa>
    {
      [HiddenInput]
      [PrimaryKey(Column = "id", Generator = PrimaryKeyType.Identity)]
      public virtual int Id { get; set; }
    
      [NotNullNotEmpty, Length(150)] // validação
      [Property("nome", NotNull = true, Length = 150, SqlType = "varchar(150)")] // mapeamento
      public virtual string Nome { get; set; }
    
      ...
    }
    
    Já no controller para criar ou editar uma pessoa fica bem mais simples e completo, já com validação e tudo mais. Sobra muito mais tempo para se preocupar em outras coisas, sem se preocupar em validar ou preencher os valores do model.

     

     

    public ActionResult Create()
    {
      return View();
    }
    
    [HttpPost]
    public ActionResult Create(Pessoa pessoa)
    {
      if (ModelState.IsValid)
      {
        pessoa.Create();
        // mensagem de sucesso
        return RedirectToAction("List");
      }
      return View(pessoa);
    }
    
    public ActionResult Edit(int id)
    {
      Pessoa pessoa = Pessoa.Find(id);
      return View(pessoa);
    }
    
    [HttpPost]
    public ActionResult Edit(Pessoa pessoa)
    {
      if (ModelState.IsValid)
      {
        pessoa.Update();
        // mensagem de sucesso
        return RedirectToAction("List");
      }
      return View(pessoa);
    }
    
    

     


    andresilva.net
    @andresilva_net
    quinta-feira, 24 de março de 2011 14:05
  • andre, deixa eu ver se eu entendi o que tu me falou

    na ideia seria a classe ter as propriedades dela e ela mesma se cadastrar no banco de dados?

    por que se voce esta falando dela ter as propriedades e suas acoes, todas estao no DO, e o DATA faz o cadastro no banco de dados.
    A WorkFrow, pega os dados da DO e passa pra DATA que por sua vez faz o cadastro do banco de dados.
    mas as vezes faz mais que isso, por exemplo, se eu tivesse que pegar os dados da Classe e gerar um pdf, essa funcionalidade estaria no WorkFlow, quanto tenho que criar DataTable, eles ficam na WorkFlow.

    e mais ou menos assim que funciona.

    tento manter a ideia de "so faz uma coisa" ai meio que acabo caindo nisso.

     

    pelo que entendi voce trabalha com uma unica solution, é isso?

    ja aproveitando que vc usa hibernate, ele esta se dando bem com procedures?
    na epoca que estudei ele, dava mais trabalho adaptar ele pra procedure do que fazer o codigo manual
    os sistemas que tenho funcionam com acesso apenas por procedures as tabelas(por questao de seguranca, o usuario que conecta enxerga apenas procedures), ninguem tem acesso diretao as tabelas.
    como que esta agora em relacao a isso?

    abs e obrigado


    Carlos Eduardo Barbosa
    Analista de Sistema
    Business Intelligence
    WEB Intelligence

    carlos.ed.b@hotmail.com

    @carlos_ed_b

    Mercúrio – Comunicação Digital

    quinta-feira, 24 de março de 2011 14:30
  • A estrutura da solution aqui é semelhante a que você utiliza, um projeto que centraliza todos os models e regras de negócio, e várias aplicações distintas que utilizam esse projeto.

    Em cada classe fica somente o que é relacionado a ela, no caso de criar um PDF teria uma classe relacionada responsável para isso, mesmo para os DataTables.

    Quanto ao uso dos procedures não houve problemas até agora. Não cheguei a usar dessa forma onde todo o acesso é feito por procedures.


    andresilva.net
    @andresilva_net
    quinta-feira, 24 de março de 2011 20:08
  • andre

    tem algum exemplo usando procedure ou me indicar o caminho das pedras?

    obrigado


    Carlos Eduardo Barbosa
    Analista de Sistema
    Business Intelligence
    WEB Intelligence

    carlos.ed.b@hotmail.com

    @carlos_ed_b

    Mercúrio – Comunicação Digital

    sexta-feira, 25 de março de 2011 14:47
  • Olá Carlos,

    Como o André disse uma boa solução é usar NHibernate.

    Eu recomendo que você leia a seguinte série de artigos pois contemplam desde a criação da solução, dependências, banco de dados, classes até a solução final com ASP.NET MVC.

     

     

    e o download completo da solução:

    http://cid-926d6677262767bd.skydrive.live.com/self.aspx/ForerunnerG34/NHibernate101%20Final.zip

     

    Abraços!


    MCPD, MCSD, MCAD, MCDBA, MCP e colaborador do 100loop.com
    quinta-feira, 7 de abril de 2011 14:06