Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

4 Answers 4

up vote 1 down vote accepted

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.
share|improve this answer

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.
share|improve this answer
    
And how would it look in a non-ideal world? :) I'm not really familiar with service oriented design, and I don't really care so much about number of calls between UI & BL right now, so I won't be making it service-oriented I guess –  BornToCode Aug 20 '12 at 21:45
    
Well... programming is always a balance between the ideal world and pragmatism and there are so many factors that go into the design of a system it's impossible to provide a single right way. If you have goals for a physical seperation (UI and BL running under seperate processes) I would try to follow the model I've mentioned above. –  Stimy Aug 20 '12 at 22:11
2  
This answer may help, but it could be improved if you could add some words what your answer to the original question is. –  Doc Brown Aug 21 '12 at 6:30
    
from this post I understood that one should use service oriented multi-tier only in cases of multiple clients\UIs, so maybe it's won't always be the ideal way? (I started learning the issue of a service layer but it looks to me like it's adding complexity to my code, so I try to avoid it whenever it's not an obligation?) –  BornToCode Sep 4 '12 at 21:28

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.

share|improve this answer
    
MVC has been the hardest thing for me to wrap my head around, I don't do any web development anymore. Abstract Repositories or Domain objects, as are Concrete Repositories. The Controller receives the Repo interface. So far, so good. What's the chain of command to add an Account? Would the Controller contain an add function which would operate as a passthrough to the Repo interface? I'm probably making this way too complicated in my head than it is. –  StyxRiver Aug 21 '12 at 17:25

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.