The exact structure of n-tier architecture RRS feed

  • General discussion

  • I have seen many programmers, making different approaches to structure their code flows :


    namespace PresentationLayer       (form)

    DropDownBox1.DataSource = SalesManager.GetCustomerBranchDetails(customer_id);
    DropDownBox1.DataTextField = "strCompanyBranch";
    DropDownBox1.DataValueField = "int32customerBranchId";

    namespace BusinessLayer, class SalesManager

    public static List<MdlCustomerDetails> GetCustomerBranchDetails(int intCustomerId)


    return dalHelper.GetDAL_SalesDetails(false).GetCustomerBranchDetails(intCustomerId);


    namespace DAL, class SalesDetails

    public List<MdlCustomerDetails> GetCustomerBranchDetails(int intCustomerId)
                return privateGetCustomerBranchDetails(intCustomerId);

    private List<MdlCustomerDetails> privateGetCustomerBranchDetails(int intCustomerId)

    { required database query in here


    This is simply for a reference. My question is for adding the items to a dropdownbox, we are traversing through 3 layers, 3 code files and 4+ methods(most of which just has a return statement).

    Is this the way to represent out coding structure or can we simplify it ?

    Wednesday, August 28, 2013 6:22 AM

All replies

  • Why are you going through the layers?


    Friday, August 30, 2013 8:46 PM
  • i thought it as the standard way to represent bigger programs. I am afraid that i am wrong.....
    Saturday, August 31, 2013 10:18 AM
  • It's not so black & white. E.g. take a look at the CQRS arch pattern. There is nothing wrong in bypassing the layers if you understand why and when you can do that. I don't know enough about your problem domain, but I'm guess that 'branch details' is pretty much tombstone data and requires little if no business logic. So I would expect to see that the data comes from a tombstoned 'read-only' store and therefore wouldn't incur any in-between layers. 


    Sunday, September 1, 2013 6:29 PM