¿Cómo debería la capa UI pasar la entrada del usuario a la capa BL?

7

Estoy creando una aplicación de n niveles, tengo UI, BL, DAL & Entidades (construidas a partir de POCO) proyectos. (Todos los proyectos tienen una referencia a las Entidades).

Mi pregunta es: ¿cómo debo pasar la entrada del usuario de la interfaz de usuario a la BL, como un conjunto de cadenas pasadas al método de BL y la BL compilará el objeto a partir de los parámetros, o debería compilar los objetos dentro de la IU? submit_function y enviar objetos como parámetros?

EDITAR: escribí n-tier application , pero lo que realmente quise decir fue solo capas.

    
pregunta BornToCode 20.08.2012 - 22:38

4 respuestas

1

how should I pass user input from the UI to the BL, as a bunch of strings passed to the BL method and the BL will build the object from the parameters, or should I build the objects inside the UI submit_function and send objects as parameters?

Prefiero enviar objetos como parámetros. Ventajas:

  1. En caso de que necesitemos más parámetros en el futuro, para ser utilizados por la capa SL / BL, podemos incluirlos sin cambiar las firmas del método en las capas Servicio, Empresa y DAO.
  2. Tener un objeto con datos puede ser reutilizado por capas. Si BL devuelve el mismo tipo de objeto, podemos reutilizar el objeto inicializado cambiando sus atributos.
  3. Código más legible. Supongamos que tiene que pasar 10-20 parámetros, en lugar de pasar todos los campos separados, recomiendo un único Objeto como parámetro.

Desventajas:

  1. Necesitamos inicializar un objeto que toma tiempo de carga y memoria.
  2. Necesitamos usar líneas de código para preparar y obtener atributos de objetos.
respondido por el Satish Pandey 09.09.2012 - 08:10
6

En una IU mundial ideal (de múltiples niveles orientada al servicio) se debe comunicar a una capa empresarial mediante contratos de datos y una fachada de servicio. La UI no debería necesitar saber nada sobre la capa de negocios real o las entidades y métodos con los que trabaja la capa de negocios. Por lo tanto, una interfaz de usuario y una fachada de servicio compartirían una definición de contrato de datos (pueden ser clases de contenedor simples o XSD). La UI llamaría a los métodos en una fachada de servicio expuesta utilizando el contrato de datos para pasar los datos comerciales de un lado a otro. Luego, depende de la fachada del servicio traducir el contrato de datos en entidades BL y llamar a los métodos BL necesarios para realizar el servicio.

¿Por qué?

  1. Esto crea una interfaz limpia entre su UI y BL basada en servicios y contratos expuestos explícita y deliberadamente. Los cambios en una capa no necesitan impactar a otra.
  2. Ayuda en la creación de pruebas unitarias automatizadas. Incluso puede probar la interfaz de usuario con implementaciones simuladas de la fachada de servicio.
  3. Impulsa un enfoque más centrado en el servicio. Se trata de servicios que están expuestos en lugar de una serie de llamadas a métodos individuales. "Con suerte", limitando el número de llamadas entre una IU y BL.
respondido por el Stimy 20.08.2012 - 23:28
1

Así es como normalmente compilo mis aplicaciones de n niveles, en este caso, usemos un proyecto de aplicación web MVC.

Una biblioteca de clases, normalmente llamada: ProjectFoo.Domain :

Aquí es donde creo mis repositorios abstractos para acceder a los datos. Por ejemplo:

public interface IAccountRepository
{
    IEnumerable<Account> FindAll();
}

También creo mis implementaciones concretas aquí, una accede a la base de datos real, la otra simplemente devuelve información simulada:

public class DbAccountRepository : IAccountRepository
{
    public IEnumerable<Account> FindAll()
    {
        DbConnector db = new DbConnector();
        return db.Accounts;
    }
}

public class MockAccountRepository : IAccountRepository
{
    public IEnumerable<Account> FindAll()
    {
        return new List<Account>(){
            new Account { Name = "Sergio", Age = 22 },
            new Account { Name = "Brad", Age = 42 },
            new Account { Name = "Chelios", Age = 32 },
        }
    }
}

A continuación, en mi proyecto de IU, normalmente llamado ProjectFoo.WebUI :

Dentro de un controlador, uso la inyección de dependencias para ordenar contra qué implementación estoy trabajando:

public class AccountController 
{
    IAccountRepository _accountRepository = new IAccountRepository();

    public AccountController(IAccountRepository accountRepository)
    { 
        _accountRepository = accountRepository;
    }

    public ActionResult Index()
    {
        // Magic! We don't need to know what exactly we're working against.
        var accounts = accountRepository.FindAll();
    }
}

Ahora en tu pregunta, How to pass user input from the UI to the BL? .

Tengo mi interfaz escrita de esta manera:

public class DbAccountRepository : IAccountRepository
{
    // Notice this is the entity object type.
    public void AddAccount(Account account)
    {
        db.AddToAccounts(account);
        db.SaveChanges();
    }
}

Toma la entrada del usuario, la configura, la valida, la ajusta dentro de un objeto POCO simple: una vez que esté seguro de que está desinfectado y funciona correctamente, use algo como AutoMapper para asignarlo a su objeto de entidad y pase el objeto completamente cargado a lo largo de la cadena hacia tu repositorio.

Si tienes alguna pregunta o no entiendes algo, avísame.

    
respondido por el sergserg 21.08.2012 - 00:51
1

Un servicio es una interfaz. Un método / función es una interfaz. Un servicio debe ser para superar cambios en las capas físicas, no capas lógicas.

Incluso podría tener una sola capa lógica que se divide en varias redes físicas y se comunica consigo misma. Por lo tanto, los servicios no deben ser una línea dura para dividir capas lógicas. Son para divisiones físicas.

Ahora, si desea que su UI y BLL tengan la flexibilidad para trabajar, ya sea en la misma caja o en otra, vaya con un servicio. De lo contrario, no es un pecado tener un método directo de llamada al bll.

    
respondido por el ttttttt 23.08.2012 - 05:05

Lea otras preguntas en las etiquetas