LINQ con 3 Tier

Question

Actualmente estoy trabajando en el diseño de mi proyecto fin de carrera. Hace unos días empecé a estudiar LINQ. Me pareció que era interesante y planeado para usarlo en mi proyecto, pero ahora estoy consiguiendo confundido en algún momento.

Cuando agrego el LINQ a SQL clase se auto genera clases de entidades contra cada tabla en la base de datos.

Supongamos que tengo dos tablas de la base de datos:

  

El usuario
  proyectos
  UserProjects (tabla conjunta)

y una mesa de conjunto que representa que el usuario se asocia con la que proyecto.

LINQ a SQL automático de clase genera estas tres clases para mí. Ahora voy a crear clases separadas (usuario y Proyecto) como Business Object o utilizar estas entidades auto generada?

Además, para utilizar la funcionalidad de la base de datos estamos obligados a usar 3 arquitectura de nivel. ¿Puedo llamar directamente método de LINQ DAL de mi BLL o tengo que crear DAL separada que llamar a un método de 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();
    }

}

es el método anterior llamando fina secuencia?

Answer 1

LINQ to SQL es grande para el diseño de un solo nivel. No tan grande para un modelo desconectado o entorno de múltiples niveles .

El código anterior sólo inserta un único usuario en la base de datos. Si el fuego de MSSQL de SQL Server o conectar hasta el registro a la salida en el estudio visual. Debería 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 actualizar el usuario el código debe mirar algo 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
}

Debe tomar la que está utilizando su contrato base de datos cada vez que se hace una unidad de trabajo. (Porque el contexto de base de datos utilizando la transacción por defecto, y esto puede poner feo, no se molestan por el rendimiento con la construcción de la base de datos de contexto! )

Por lo general, cuando se trabaja con un entorno de múltiples niveles, debe crear una separada POCO ' s al pasar ellos sobre el alambre (de red).

NCommon es una gran abstracción para LINQ to SQL, debe manejar la validación y reglas de negocio .

Nota. Su buena práctica valores hash de la contraseña en una base de datos.

de ScottGu para un rápido Q & A y conceptos básicos sobre LINQ

Answer 2

Normalmente crear una clase de ámbito DataContext para cada uno de mis objetos BLL.

También crear 2 constructores, 1 que crea un DataContext y otra que acepta un DataContext. La segunda es para que pueda pasar alrededor de un DataContext de otros objetos BLL.

Esto le permite realizar operaciones de bases de datos en los objetos que puedan proceder de 2 objetos diferentes BLL mientras que todavía conserva una buena separación de las preocupaciones. También tendrá que exponer el DataContext como de sólo lectura pública para que pueda pasar alrededor.

Algo a destacar es que un objeto DataContext no tiene que estar dispuesto especifique lo contrario, más información aquí . Pero básicamente el DataContext sólo vivir por el tiempo de vida del objeto BLL. Se puede disponer de ella de forma explícita, aunque si realmente se necesita para liberar los recursos (es decir, el seguimiento de cambios que haya terminado).

por ejemplo.

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();
    }
}