In che modo lo strato UI deve passare l'input dell'utente allo strato BL?

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?

L'invio di oggetti come parametri sono preferibili da me. Vantaggi:

1. Nel caso in cui avessimo bisogno di più parametri in futuro, per essere utilizzati dal livello SL / BL, possiamo includerli senza modificare le firme dei metodi nei livelli Service, Business e DAO.
2. Avere un oggetto con i dati può essere riutilizzato dai livelli. Se BL restituisce lo stesso tipo di oggetto, possiamo riutilizzare l'oggetto inizializzato modificandone gli attributi.
3. Codice più leggibile. Supponiamo di dover passare 10-20 parametri, piuttosto di passare tutti quelli in campi separati. Raccomando un singolo oggetto come parametro.

Svantaggi:

1. Abbiamo bisogno di inizializzare un oggetto che richiede tempo di caricamento e memoria.
2. Abbiamo bisogno di utilizzare linee di codice per preparare e recuperare gli attributi degli oggetti.

In una UI mondiale ideale (orientata ai servizi a più livelli) è necessario comunicare a un livello aziendale tramite contratti di dati e una facciata di servizio. L'interfaccia utente non dovrebbe avere bisogno di sapere nulla sul livello aziendale attuale o sulle entità e sui metodi con cui il livello aziendale lavora. Quindi un'interfaccia utente e una facciata di servizio dovrebbero condividere una definizione di contratto dati (possono essere classi contenitore semplici o XSD). L'interfaccia utente chiamerebbe i metodi su una facciata di servizio esposta utilizzando il contratto di dati per trasmettere i dati aziendali avanti e indietro. Spetta quindi alla facciata del servizio tradurre il contratto dati in entità BL e chiamare i metodi BL necessari per eseguire il servizio.

Perché?

1. Ciò crea un'interfaccia pulita tra l'interfaccia utente e BL basata su servizi e contratti esplicitamente ed esplicitamente esposti. Le modifiche in un livello non devono influire su un altro.
2. Aiuta nella creazione di test unitari automatizzati. È anche possibile testare l'interfaccia utente con finte implementazioni della facciata del servizio.
3. Spinge per un approccio più orientato al servizio. Sono i servizi che vengono esposti piuttosto che una serie di chiamate di metodo individuali. "Speriamo" che limiti il numero di chiamate tra un'interfaccia utente e BL.

Ecco come di solito realizzo le mie applicazioni a più livelli, in questo caso, utilizziamo un progetto di applicazione Web MVC.

Una libreria di classi, in genere chiamata: ProjectFoo.Domain :

Ecco dove creo i miei repository astratti per l'accesso ai dati. Ad esempio:

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

Creo anche le mie implementazioni concrete qui, uno accede al database reale, l'altro restituisce solo informazioni fittizie:

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 },
        }
    }
}

Successivamente, nel mio progetto di interfaccia utente, in genere chiamato ProjectFoo.WebUI :

All'interno di un controller uso l'injection dependency per risolvere l'implementazione a cui sto lavorando:

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

Ora sulla tua domanda, How to pass user input from the UI to the BL? .

Ho scritto la mia interfaccia in questo modo:

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

Acquisisci input, modellalo, convalidalo, inseriscilo in un semplice oggetto POCO - una volta che sei sicuro che sia sterilizzato e funzioni correttamente, usa qualcosa come AutoMapper per mappare il tuo oggetto entità e passare l'oggetto completamente caricato lungo la catena verso il tuo repository.

Se hai qualche domanda o non capisci qualcosa fammelo sapere.

Un servizio è un'interfaccia. Un metodo / funzione è un'interfaccia. Un servizio dovrebbe essere per superare le modifiche ai livelli fisici, non ai livelli logici.

Potresti persino avere un singolo livello logico che è suddiviso su più reti fisiche e comunica con se stesso. Quindi i servizi non dovrebbero essere una linea dura per dividere i livelli logici. Sono per le divisioni fisiche.

Ora, se vuoi che l'interfaccia utente e la BLL abbiano la flessibilità di lavorare sia sulla stessa casella che su un'altra, allora vai con un servizio. Altrimenti non è un peccato avere una chiamata di metodo diretta al bll.