Ainda não tem acesso? Estude com a gente! Matricule-se
Ainda não tem acesso? Estude com a gente! Matricule-se

Solucionado (ver solução)

MÉTODOS COM REGRAS DE NEGÓCIO EM CLASSES DE DOMÍNIO OU EM CLASSES DA CAMADA DE NEGÓCIO (BLL)?

Entrei em contato com o professor do curso "Design Patterns para bons programadores em C#", o Maurício Aniche, perguntando sobre a seguinte situação:

Vejo que nos exemplos das aulas há, em todas as classes, métodos simulando regras de negócio. O que você me diz, tendo em mente as boas práticas de programação, das classes de negócio, contidas na camada de negócio?

Podemos criar classes somente com seus atributos e colocar tais métodos com regras de negócio nas classes de negócio ou não? Deveríamos ter métodos, mesmo contendo regras de negócio, na própria classe?

E obtive a seguinte a resposta do professor:

Não entendi sua dúvida. Todas as classes que mostrei no curso são classes de domínio e contém regras de negócio. A ideia é sempre você deixar atributos e comportamentos perto, sem dúvida. Separamos isso só quando realmente precisamos de flexibilidade (veja o Strategy, por exemplo, onde temos uma classe só com regra de negócio).

É isso?

Continuando a dúvida e, com uma explicação melhor:

A dúvida é se crio nas classes de domínio atributos e métodos contendo regras de negócio ou se crio apenas os atributos e separo os métodos que contém regras de negócio nas classes de negócio, contidas na camada de negócio (BLL)?

Exemplos (Duas situações. Qual é a certa?):

Camada de Entidades > Classes de domínio somente com atributos e Camada de Negócio (BLL) > Classes de negócio com métodos que contém regras de negócio

ou

Camada de Entidades > Classes de domínio com atributos e métodos que contém regras de negócio e Camada de negócio (BLL) > Classes de negócio com métodos que contém outras regras de negócio.

Considerando que um projeto ASP.NET WebForms contenha 4 camadas (DAL, BLL, PL e Entidades):

  • DAL > Acesso a dados
  • BLL > Regras de negócio
  • PL > Views ou Interfaces de usuário
  • Entidades > Classes de domínio

Espero que tenha explicado melhor...

Desde já, grato;

Diogo Marins

5 respostas

Vamos tentar responder, o grande problema da sua pergunta me parece estar no BLL, do qua nada mais é do que uma antiga camada de negócio apartada. Note que conforme estamos aprendendo aqui nesse curso, nosso MODELO de classes passa a se tornar mais forte, é é nele que a camada de negócio será construída. E a BLL? Vamos tentar mudar o paradigma, que tal um modelo orientado a serviços onde nossas requisições seriam mais autônomas e tb mais distantes do MODELO. E ficaria assim PL>>BLL>MODELO>>DAL, a essa altura já estamos com uma representação muito parecida com o MVC, porém com uma camada a mais de Serviços. Espero que tenha ajudado.

solução

Oi Diogo,

Essa arquitetura, onde temos regras de negócio de um lado, e atributos de outro, é conhecida por modelo anêmico. Como o próprio nome já diz, não é uma boa ideia. Se você googlar, vai encontrar muito material sobre isso.

Mas o problema básico é que quando você separa dados de comportamento, você está jogando fora todos os benefícios da orientação a objetos, como reuso, extensão, polimorfismo, etc.

No exemplo do curso, eu só escrevi código de domínio. Classes com atributos e regras de negócio. Se sua aplicação é web, você terá então uma camada (os controllers, por exemplo), que farão uso dessas classes de domínio.

Entendeu?

Caí de paraquedas aqui, mas qual seria então o melhor padrão para se trabalhar com Entity Framework em um projeto Web?

Projeto com Entity do lado de fora contendo as regras de negocio e um projeto web a parte?

Olá Felipe

As observações do maurício valem inclusive para projetos em que utilizamos o entity framework. Nesse tipo de projeto, colocar a regra de negócio mais perto da entidade ajuda a manter a consistência das informações no banco de dados.

Sobre a separação do projeto, ela só deve ser feita se necessário. Quando quebramos a aplicação em diversos projetos separados estamos gerando complexidade no código, o que acaba dificultando a manutenção futura.

Bom, pessoal... Entendi a questão e obrigado pela dúvida.