Pergunta

O projeto que estou trabalhando está usando a arquitetura n-tier. Nossos camadas são os seguintes:

  • Acesso a dados
  • Business Logic
  • Entidades de Negócios
  • Apresentação

A lógica do negócio chama para dentro da camada de acesso a dados, e a camada de apresentação chama-se para a camada de lógica de negócios e as entidades de negócios são referenciados por todos eles.

As nossas entidades empresariais essencialmente coincidir com o nosso modelo de dados 1-1. Para cada mesa, temos uma classe. Inicialmente, quando a estrutura foi projetado, não havia nenhuma consideração para o gerenciamento de mestre-detalhe ou filho de pais relacionamentos. Então, toda a lógica de negócios, acesso a dados e entidades empresariais, única referenciada uma única tabela no banco de dados. Uma vez que começamos a desenvolver a aplicação rapidamente se tornou evidente que não ter essas relações em nosso modelo de objeto foi nos prejudicando severamente.

Todas as suas camadas (incluindo o banco de dados) são todos gerados a partir de um metadados do banco de dados in-house que usamos para conduzir o nosso gerador de código home-grown.

A questão é qual é a melhor maneira de carga ou carga preguiçoso os relacionamentos em nossas entidades. Por exemplo Vamos dizer que temos uma classe pessoa que tem uma relação mestre-criança a uma tabela de endereços. Isto mostra-nos a entidade empresarial como uma propriedade coleção de Endereços sobre o objeto Pessoa. Se nós temos um relacionamento um-para-um, então isso iria mostrar-se como uma única propriedade entidade. Qual é a melhor abordagem para o enchimento e salvar os objetos de relacionamento? entidades nosso negócio não têm conhecimento da camada de lógica de negócios, por isso não pode ser feito internamente quando a propriedade do get chamado.

Estou certo que há algum tipo de patter padrão lá fora para fazer isso. Alguma sugestão?

Além disso, uma ressalva é que a camada DataAcess usa reflexão para construir nossas entidades. Os procedimentos armazenados retornar um resultado selt com base em uma tabela, e usando a reflexão que povoam o nosso objeto de negócios, combinando os nomes das propriedades com os nomes das colunas. Assim fazendo junções seria difícil.

Foi útil?

Solução

Eu recomendo altamente olhando para Padrões de Enterprise Architecture livro de Fowler. Existem algumas abordagens diferentes para resolver este tipo de problema que ele descreve muito bem, incluindo relacionamentos de entidade.

Um dos itens mais atraente seria a Unidade de trabalho padrão, que é basicamente um colecionador, que observa as ações realizadas em suas entidades, e uma vez que seu feito com a sua ação, ele lotes as chamadas de banco de dados apropriadas, e faz o solicitar ao banco de dados. Este padrão é um dos conceitos fundamentais utilizados por NHibernate , que utiliza um objecto que implementa a IDisposable sinalizar o fim do "trabalho". Isso permite que você enrole suas ações em um usando, e ter a unidade de negócio de trabalho com as ações para você.

Editar: Informações adicionais

Este é um link para a estrutura de classes básica da Unidade de Trabalho ... não é realmente a coisa emocionante a maioria no mundo. Fowler fornece mais detalhes em seu livro, alguns dos quais você pode ver aqui . Você também pode olhar para o objeto de sessão do NHibernate como uma possível implementação (eu era capaz de rastrear o interface de ISession ... não tenho certeza onde as vidas de implementação)

Espero que isso ajude.

Outras dicas

Uma abordagem que eu usei no passado é fazer o suficiente inteligente tipo de recipiente para buscar os objetos necessários. por exemplo:

public class Relation<T>
{
  private T _value;

  private void FetchData()
  {
    if( LoadData != null ) {
      LoadDataEventArgs args = new LoadDataEventArgs(typeof(T), /* magic to get correct object */);
      LoadData(this, args);
      _value = (T)args.Value;
    }
  }

  public event EventHandler<LoadDataEventArgs> LoadData;

  public T Value {
    get {
      if( _value == default(T) )
        FetchData();
      return _value; 
    }
    set { /* Do magic here. */ }
  }
}

Em seguida, você declará-lo na sua entidade como:

[RelationCriteria("ID", EqualsMyProperty="AddressID")]
public Relation<Address> Address {
  get; set;
}

E é até o carregador do tipo que declara a propriedade de endereços para adicionar um manipulador para o evento LoadData.

A classe implementa semelhantes IList para dar-lhe um um-para-muitos.

Que linguagem você está usando? O que você descreveu é exatamente o que o Entity Framework faz em .Net. Mas você não partilharam que língua você estava usando e eu estou supondo que você não quer reescrever qualquer um dos seus dataLayer.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top