none
Three Tier : How do three layers communicate ? ( Detailed ) RRS feed

  • Question

  • In a .NET 2.0,

    If a design my application three layered desktop application ( ie. Presentation, Business and Data layer ). How do my three layers located on three different machines, communicate with each other ?

    Thanks,

    Friday, March 21, 2008 5:12 PM

Answers

  •  Navdeep wrote:
     

    I am glad you asked but not sure if I can answer this. I can briefly say design will have clients -> application server-> Database server ie there different physical machines. This is the scenario and I plan to put BL on app server and dal +  DB on database server alternatively BL and DAL can be on App server and DB on database server. But I was wondering how to implement the former.

     

    Ok, look if you have often different tiers make sense when each tier can generate reasonable load. But DAL cannot generate this load. It always nothing not more then transformer from datasource (e.g.Database, XML) and object suitable for programming. This is why this is much more common to make application tier(BL and DAL) and Database tier. In this case BL and DAL will generate load and Database will generate its own load.

     

    In your case one possible answer to my question is to allow remote access to the database. Something like your database is in inner network that firewalled and your application(BLL Tier) should access to it from outside of this network. But if is this not your case you should consider to design your DAL and BLL as one tier.

     Navdeep wrote:

    How can we do that with .Net remoting ( no .NET 3.0 )

    Cannot find how to attach files Sad, so no diagram...

     

    This solution can be considered as overcomplicated. At I do not think that it has business value. Any way.

     

    Data Tier

    --- Database

    DAL Tier

    --- DAL

    --- Formal BLL(can be stripped out)

    --- Presentation (.Net Remoting façade)

    BLL Tier

    --- DAL (.Net Remoting Client)

    --- Real BLL

    --- Presentation

     

    Main point is that if you develop separate tiers they should be treated as application. This is why this is large amount of plumbing code to write. And if you do not have strong reason (e.g. I have described below) you should not use it.

    Sunday, March 23, 2008 4:35 PM

All replies

  • We used Webservice (.NET 2.0) as Service Interface among the layers...  All the entity objects that cross the layers were serialized...

     

    Other option could be .NET remoting, but we wanted to expose the application domain as service interface to ESB, hence used webservice...

     

    Ofcourse in .NET 3.x you would be using WCF...

    Friday, March 21, 2008 7:14 PM
  •  GajaKannan wrote:

    We used Webservice (.NET 2.0) as Service Interface among the layers...  All the entity objects that cross the layers were serialized...

     

    Other option could be .NET remoting, but we wanted to expose the application domain as service interface to ESB, hence used webservice...

     

    Ofcourse in .NET 3.x you would be using WCF...



    .NET 3.0 is currently out of picture but Remoting is a good option but "how" business layer would call Data layer... conceptually.
    Saturday, March 22, 2008 1:14 AM
  • DAL and BL are running in different appdomains have DAL return all serialized datatables to BL through remoting, same as BL to UI...

     

    If DAL and BL are running in the same app domain, just different projects, then assembly reference is enough...

    Sunday, March 23, 2008 3:04 PM
  •  GajaKannan wrote:

    DAL and BL are running in different appdomains have DAL return all serialized datatables to BL through remoting, same as BL to UI...

     



    I will consider different appdomain as three layer on three different physical machines ( although I guess same machine can have different appdomains ).

    In case of remoting,  do we need two remoting servers ie. one at BL to serve UI and one at DAL to serve BL ?




    Sunday, March 23, 2008 3:16 PM
  •  Navdeep wrote:
    Remoting is a good option but "how" business layer would call Data layer... conceptually.

    This is not common practice to develop BLL and DAL to resists in separate application domains. Can you describe WHY do you need such architecture?

    This is not direct answer to your question, but I will rather design BLL and DAL as separate assemblies that will live in SINGLE application domain. Really, I cannot see any benefits to have BLL and DAL as separate application domains, rather many problemsSmile.

    Also I can add that in situation when I need remote access the the DAL, I will treat DAL application domain as whole application with its own DAL, BLL(thin) and Presentation(.Net Remoting, WCF, ACMX) and in turn BLL application domain will have its own DAL(.Net Remoting, WCF, ACMX).

    Sunday, March 23, 2008 3:30 PM
  •  Mike Chaliy wrote:

     Navdeep wrote:
    Remoting is a good option but "how" business layer would call Data layer... conceptually.

    Can you describe WHY do you need such architecture?

    This is not direct answer to your question, but I will rather design BLL and DAL as separate assemblies that will live in SINGLE application domain. Really, I cannot see any benefits to have BLL and DAL as separate application domains, rather many problems.




    I am glad you asked but not sure if I can answer this. I can briefly say design will have clients -> application server-> Database server ie there different physical machines. This is the scenario and I plan to put BL on app server and dal +  DB on database server alternatively BL and DAL can be on App server and DB on database server. But I was wondering how to implement the former.

     Mike Chaliy wrote:

    Also I can add that in situation when I need remote access the the DAL, I will treat DAL application domain as whole application with its own DAL, BLL(thin) and Presentation(.Net Remoting, WCF, ACMX) and in turn BLL application domain will have its own DAL(.Net Remoting, WCF, ACMX).


    How can we do that with .Net remoting ( no .NET 3.0 )

    Sunday, March 23, 2008 3:55 PM
  •  Navdeep wrote:
     

    I am glad you asked but not sure if I can answer this. I can briefly say design will have clients -> application server-> Database server ie there different physical machines. This is the scenario and I plan to put BL on app server and dal +  DB on database server alternatively BL and DAL can be on App server and DB on database server. But I was wondering how to implement the former.

     

    Ok, look if you have often different tiers make sense when each tier can generate reasonable load. But DAL cannot generate this load. It always nothing not more then transformer from datasource (e.g.Database, XML) and object suitable for programming. This is why this is much more common to make application tier(BL and DAL) and Database tier. In this case BL and DAL will generate load and Database will generate its own load.

     

    In your case one possible answer to my question is to allow remote access to the database. Something like your database is in inner network that firewalled and your application(BLL Tier) should access to it from outside of this network. But if is this not your case you should consider to design your DAL and BLL as one tier.

     Navdeep wrote:

    How can we do that with .Net remoting ( no .NET 3.0 )

    Cannot find how to attach files Sad, so no diagram...

     

    This solution can be considered as overcomplicated. At I do not think that it has business value. Any way.

     

    Data Tier

    --- Database

    DAL Tier

    --- DAL

    --- Formal BLL(can be stripped out)

    --- Presentation (.Net Remoting façade)

    BLL Tier

    --- DAL (.Net Remoting Client)

    --- Real BLL

    --- Presentation

     

    Main point is that if you develop separate tiers they should be treated as application. This is why this is large amount of plumbing code to write. And if you do not have strong reason (e.g. I have described below) you should not use it.

    Sunday, March 23, 2008 4:35 PM
  •  Mike Chaliy wrote:

    to allow remote access to the database. Something like your database is in inner network that firewalled and your application(BLL Tier) should access to it from outside of this network.


     

    This solution can be considered as overcomplicated. At I do not think that it has business value. Any way.

     

    Data Tier

    --- Database

    DAL Tier

    --- DAL

    --- Formal BLL(can be stripped out)

    --- Presentation (.Net Remoting façade)

    BLL Tier

    --- DAL (.Net Remoting Client)

    --- Real BLL

    --- Presentation

     

    Main point is that if you develop separate tiers they should be treated as application. This is why this is large amount of plumbing code to write. And if you do not have strong reason (e.g. I have described below) you should not use it.



    Thanks Mike for your time.
    Yes you are right in above quoted scenario. I need little indepth of layers, you designed above. How to actually code ( some pseudo-code will do )

    DAL Tier
    • Formal BLL
    • Presentation (.Net Remoting façade)
    Also,
    1. I guess DAL Tier will "talk" to DATA Tier with ADO.NET.
    2. DAL Tier --> BLL tier as quoted above ( some pseudo code )
    3. How will BLL talk to UI

    Thanks,
    Navdeep

    Sunday, March 23, 2008 4:58 PM
  •  Navdeep wrote:

    Thanks Mike for your time.
    Yes you are right in above quoted scenario. I need little indepth of layers, you designed above. How to actually code ( some pseudo-code will do )

    DAL Tier

    • Formal BLL
    • Presentation (.Net Remoting façade)
    Also,
    1. I guess DAL Tier will "talk" to DATA Tier with ADO.NET.
    2. DAL Tier --> BLL tier as quoted above ( some pseudo code )
    3. How will BLL talk to UI


    Thanks,
    Navdeep

     

    Some pseudo code, per request. Other thing that this code is not illustrate something... Also it has number of the drawbacks, example is single object for DAL and Presentation. Also BLL(from DAL Tier) is tripped out completely Smile.

     

    Code Snippet

    /// <summary>
    ///  Actual data object, please note that id DOES NOT has logic, it DOES NOT has methods!
    /// </summary>
    public class Customer
    {
    }

    /// <summary>
    ///  Abstraction for your store, this is out of the scope of this example...
    /// </summary>
    public interface ICustomerStore
    {
     IEnumerable<Customer> SelectCustomers();
    }

    /// <summary>
    ///  Implementation of the store.
    /// </summary>
    public class CustomerStore : ICustomerStore
    {
     #region ICustomerStore Members

     public IEnumerable<Customer> SelectCustomers()
     {
      // DAL Specific code here you should instantiate and fill Customer objects
     }

     #endregion
    }

    /// <summary>
    ///  This is common interface of the remoting facade;
    /// </summary>
    public interface ICustomerManager
    {
     public Customer[] GetCustomers();
    }

    /// <summary>
    ///  This is .Net Remoting facade;
    /// </summary>
    public class CustomerManager : MarshalByRefObject, ICustomerManager
    {
     #region ICustomerManager Members

     public Customer[] GetCustomers()
     {
      ICustomerStore store = this.GetService(typeof(ICustomerStore));
      // filtration, permissions check and so on goes here;
      return store.SelectCustomers();
     }

     #endregion
    }

     

     

    >>I guess DAL Tier will "talk" to DATA Tier with ADO.NET.

    Yep. If you can look on LINQ.

    >>DAL Tier --> BLL tier as quoted above ( some pseudo code )

    BLL should consume .Net Remoting service as any regular client. Nothing specific here.

    >>How will BLL talk to UI

    ASP.Net or WinForms? If ASP.Net I definitely recommend in-process, but also can be .Net Remoting. If WinForms - ASMX. ASMX is more slow solution in comparison to .Net Remoting but it provide much more interoperability, also it is much easy to migrate to WCF in future.

     

    With such number of distributed components you also should plan security. Seems you have too much clouds...

     

    I what to stress that this is overcomplicated. Even large application in many cases consider something less complex.

    Sunday, March 23, 2008 5:31 PM
  •  Mike Chaliy wrote:


    >>DAL Tier --> BLL tier as quoted above ( some pseudo code )

    BLL should consume .Net Remoting service as any regular client. Nothing specific here.

    >>How will BLL talk to UI

    ASP.Net or WinForms? If ASP.Net I definitely recommend in-process, but also can be .Net Remoting. If WinForms - ASMX. ASMX is more slow solution in comparison to .Net Remoting but it provide much more interoperability, also it is much easy to migrate to WCF in future.

     



    For me UI will be WinForms.
    Now to as far as "talking" is concerned I summarize as below

    DAL Tier --> BLL tier
    through remoting

    BLL talk to UI
    through remoting.

    Does that mean BLL as well as DAL will have one remoting server each. So that
    DAL remoting server serves BLL and
    Remoting server on BLL serves UI ?

    Thanks.



    Sunday, March 23, 2008 5:48 PM
  • I think Mike hit on a salient point here. If you're asking simple questions about how to implement tier comms, do you really know that you need them? To put it another way, n-tier physical design is typically only needed in a pretty high enterprise problem, or for something you know is going to be SOA like. I might be making huge assumption here but it sounds to me like you'd need one SQL Sever, one Application Server and your desktop app. So, as Mike suggests, WCF from client to app server and then ADO.NET to SQL would be all you need. Obvisouly I'd recommend you designing your logical layers so you could easily put WCF inbetween them should you ever need to scale out but I doubt you need to do that now?

    Monday, March 24, 2008 12:08 AM