LINQ com 3 Camada

Question

Atualmente estou trabalhando no projeto do meu projeto de graduação. Alguns dias atrás eu comecei a estudar LINQ. Eu achei que era interessante e planejado para usá-lo no meu projeto, mas agora estou ficando confuso em algum ponto.

Quando eu adiciono o LINQ to SQL classe que auto gera classes entidades contra cada tabela no banco de dados.

Suponha que eu tenho duas tabelas no banco de dados:

Usuário projetos
UserProjects (tabela conjunta)

e uma mesa conjunta que representa o usuário que está associado com qual projeto.

LINQ to SQL classe auto gera essas três classes para mim. Agora vou criar classes separadas (User e Projeto) como negócio objeto ou usar estes auto entidades geradas?

Além disso, a funcionalidade de banco de dados uso que são obrigados a usar 3 tier. Posso chamar diretamente método LINQ DAL do meu BLL ou que eu preciso para criar DAL separado, que irá chamar um método do LINQ DAL ??

class UserBLL

{
    public void saveUser(String username, String password)
    {
         // here I am calling LINQ DAL from by BLL
         UserDataContext db = new UserDataContext();
         User u =new User {Username = username, Password = password};
        db.user.InsertOnSubmit(u);
       db.SubmitChanges();
    }

}

É o método acima chamando seqüência bem?

Answer 1

LINQ to SQL é grande para o design único nível. Não tão grande para um modelo desconectado ou ambiente multi camadas .

O código acima só insere um único usuário no banco de dados. Se você fogo até MSSQL SQL Server Profiler ou conecte-se o registo para a saída no estúdio visual. Você deve ver

//Hookup the log to the output in visual studio
using (var db = new UserDataContext()) {
    db.Log = Console.Out;
}

INSERT INTO User VALUES (value1, value2, value3,...)

Para atualizar o usuário o código deve olhar para somthing como

public void UpdateUser(String username, String password, int userId)
{
     using (var db = new UserDataContext()) {
         //Get Row From Database Marching Id
         var user = db.user.Single(p => p.Id = userId);
         //Update Values
         user.Username = username;
         user.Password = password;
         //Save To The Database
         db.SubmitChanges();
     }
}

//Get All Users From Database
public IEnumerable<User> GetAllUsers()
{
     using (var db = new UserDataContext()) {
         //Get Row From Database Matching Id
         var users = from user in db.user
                    select user;
         return users.ToList();
     }
}

//To display the data just enumerate through the enumeration that is returned.
var users = BusinessInstance.GetAllUsers();
foreach (var user in users) {
    //user is the current item
}

Você deve fazer a sua que você está usando o seu contrato de banco de dados cada vez que fizer uma unidade de trabalho. (Porque o contexto de banco de dados usando a transação por padrão, e isso pode ficar feio, não se preocupar com o desempenho com a construção do contexto do banco de dados! )

Normalmente, quando você trabalha com um ambiente multi camadas, você criaria um independentes POCO ' s ao passá-los ao longo do arame (rede).

NCommon é uma grande abstração para LINQ to SQL, deve lidar com a validação de negócios e regras .

Nota. Sua boa prática valores hash de senha em um banco de dados.

Confira de ScottGu blog para um Q & A e básico rápido em linq

Answer 2

Eu normalmente criar uma classe com escopo datacontext para cada um dos meus objetos BLL.

Eu também criar 2 construtores, 1, que cria um datacontext e outra que aceita um datacontext. A segunda é para que eu possa passar em torno de um datacontext de outros objetos BLL.

Isso permite que você execute operações de banco de dados em objetos que podem ter vindo de 2 BLL diferentes objetos, embora mantendo uma boa separação de interesses. Você também vai precisar para expor o datacontext como público somente leitura para que ele possa ser passado ao redor.

Algo a notar é que um objeto DataContext não tem que ser explicitamente descartado, mais informações aqui . Mas basicamente o DataContext só vai ao vivo para a vida útil do objeto BLL. Você pode explicitamente descartá-lo embora se você realmente precisa para liberar os recursos (ou seja, você tem controle de alterações acabados).

por exemplo.

public class UserBLL
{
    private readonly UserDataContext context;

    public UserBLL() : this(new UserDataContext())
    {
    }

    public UserBLL(UserDataContext context)
    {
        this.context = context
    }

    public UserDataContext Context { get { return context; } }

    public void saveUser(String username, String password)
    {
         // here i am callsing LINQ DAL from by BLL
         User u = new User {Username = username, Password = password};
         Context.Users.InsertOnSubmit(u);
         Context.SubmitChanges();
    }
}