How should UI layer pass user input to BL layer?

Question

I'm building an n-tier application, I have UI, BL, DAL & Entities (built from POCO) projects. (All projects have a reference to the Entities).

My question is - 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?

EDIT: I wrote n-tier application, but what I actually meant was just layers.

Answer 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?

Sending Objects as parameters are preferable by me. Advantages:

1. In case if we need more parameters in future, to be used by SL/BL layer we can include them without changing the method signatures in Service, Business and DAO layers.
2. Having a object with data can be reused by layers. If BL returns the same object type we can reuse the initialized object by changing its attributes.
3. More readable code. Suppose you have to pass 10-20 parameters, rather passing all those in separate fields I recommend a single Object as parameter.

Disadvantages:

1. We need to initialize a object that takes load time and memory.
2. We need to use lines of code to prepare and fetch object attributes.

Answer 2

In an ideal (service oriented multi-tier) world UI should communicate to a business layer through data contracts and a service facade. The UI should not need to know anything about the actual business layer or the entities and methods the business layer works with. So a UI and service facade would share a data contract definition (these can be simple container classes or XSD's). The UI would call methods on an exposed service facade using the data contract to pass the business data back and forth. It's then up to the service facade to translate the data contract into BL entities and call the BL methods necessary to perform the service.

Why?

1. This creates a clean interface between your UI and BL based on purposely and explicitly exposed services and contracts. Changes in one layer do not need to impact another.
2. It aids in creation of automated unit tests. You can even test the UI with mock implementations of the service facade.
3. It pushes for a more service focused approach. It is services that are exposed rather than a series of individual method calls. "Hopefully" limiting the number of calls between a UI and BL.

Answer 3

Here's how I typically build my n-tier applications, in this case, let's use an MVC web application project.

A class library, typically called: ProjectFoo.Domain:

Here's where I create my abstract repositories for accessing data. For example:

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

I also create my concrete implementations here, one accesses the real database, the other just returns mock information:

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

---

Next, in my UI project, typically called ProjectFoo.WebUI:

Inside a controller I use dependency injection to sort out what implementation I'm working against:

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

---

Now onto your question, How to pass user input from the UI to the BL?.

I have my interface written like this:

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

Grab user input, shape it, validate it, fit it inside a simple POCO object - once you're sure it's sanitized and functioning correctly, use something like AutoMapper to map to your entity object and pass fully loaded object along the chain towards your repository.

If you have any question or don't quite understand something let me know.

Answer 4

A service is an interface. A method/function is an interface. A service should be for overcoming changes to the physical layers, not logical layers.

You could even have a single logical layer that is split over several physical networks and communicates with itself. So services should not be a hard-line for splitting logical layers. They are for physical splits.

Now if you want your UI and BLL to have the flexibility to work whether on the same box or different, then go with a service. Otherwise it's not a sin to have a direct method call to the bll.