title: 3-layer architecture - passing data between layers
body: <p>Trying to implement 3-layer (not: tier, I just want to separate my project logically, on one machine) architecture I've found so many different approaches that I'm confused, what's the best way (if there's any) to make that in WinForms app.  </p>
  
  <p>Now I have no doubts only about 3 layers that should be present in the project:  </p>
  
  <ul>
  <li>UI (Presentation Layer)  </li>
  <li>BLL (Business Logic Layer)  </li>
  <li>DAL (Data Acces Layer)  </li>
  </ul>
  
  <p>In <strong>UI</strong> I put all the WinForms. There must be also some logic to fill the object with data from controls and pass it to BLL layer.  </p>
  
  <p>In <strong>DAL</strong> I want to put classes and methods for data manipulations using ADO.NET, like: </p>
  
  <pre><code>public class OrderDAL
  {
      public OrderDAL()
      {
      }
  
      public int Add(Order order)
      {
          //...add order to database
      }
  
      public int Update(Order order)
      {
          //...update order in database
      }
  
      //...etc.
  }
  </code></pre>
  
  <p>The problem is with BLL and the question - should I use <strong>Data Transfer Objects</strong> to pass data between layers, or should I pass the whole Class?</p>
  
  <p>If I choose to use <strong>DTO</strong>, then I've to create additional common class, <code>Order</code>, that reference to UI, BLL and DAL:  </p>
  
  <pre><code>public class Order
  {
      public int Id { get; set; }
      public DateTime Date { get; set; }
      public string Number { get; set; }
      public string CustomerName { get; set; }
  
      public Order ()
      {
      }
  }
  </code></pre>
  
  <p>and put the logic <strong>separated</strong> into BLL:</p>
  
  <pre><code>public class OrderBLL
  {
      public OrderBLL()
      {
      }
  
      public int Add(Order order)
      {
          OrderDAL orderDAL = new OrderDAL();
          return orderDAL.Add(order);
      }
  
      public int Update(Order order)
      {
          OrderDAL orderDAL = new OrderDAL();
          return orderDAL.Update(order);
      }
  
      //...etc.
  }
  </code></pre>
  
  <p>This approach, under different names, is used among others: <a href="http://www.codeproject.com/Articles/36847/Three-Layer-Architecture-in-C-NET" rel="noreferrer">here</a> or <a href="http://www.aspdotnet-suresh.com/2010/05/introduction-to-3-tier-architecture-in_17.html" rel="noreferrer">here</a>.<br>
  On the other hand, some "wise guys" and their followers (like <a href="http://martinfowler.com/bliki/AnemicDomainModel.html" rel="noreferrer">here</a>) call it <a href="http://en.wikipedia.org/wiki/Anemic_domain_model" rel="noreferrer">Anemic Domain Model</a> and complain it's a bad design and anti-pattern that should not be used.  </p>
  
  <p><strong>The pros:</strong> </p>
  
  <ul>
  <li>DTO can easily by design to represent Database table,</li>
  <li>it's light and clear, contains only fields needed for database,</li>
  <li>DAL doesn't have to reference BLL,</li>
  </ul>
  
  <p><strong>The cons:</strong> </p>
  
  <ul>
  <li>anti-pattern (sounds scary ;P),</li>
  <li>violation of OOP (separated properties from methods),</li>
  <li>because logic is in different class, it may be more difficult to maintain when something changes.</li>
  </ul>
  
  <p>So, the opposite approach is to pass the whole object between layers, like <a href="http://www.codeproject.com/Articles/11128/3-tier-architecture-in-C" rel="noreferrer">here</a>: no DTO, just BLL looking like that:</p>
  
  <pre><code>public class Order
  {
      public int Id { get; set; }
      public DateTime Date { get; set; }
      public string Number { get; set; }
      public string CustomerName { get; set; }
  
      public Order()
      {
      }
  
      public int Add()
      {
          OrderDAL orderDAL = new OrderDAL();
          return orderDAL.Add(this);
      }
  
      public int Update(Order order)
      {
          OrderDAL orderDAL = new OrderDAL();
          return orderDAL.Update(order);
      }
  }
  </code></pre>
  
  <p><strong>The pros:</strong> </p>
  
  <ul>
  <li>it's a nicely encapsulated object, following OOP rules (I suppose ;)). </li>
  <li>both logic and properties are in one place, easier to maintain and debug.</li>
  </ul>
  
  <p><strong>The cons:</strong> </p>
  
  <ul>
  <li>to use the object, DAL has to reference BLL (that's not how the 3-tier layer should do, isn't it?). </li>
  <li>class may contain some fields that are not used in Database, as well as some fields from Database (like Id) do not represent "real life" object.</li>
  </ul>
  
  <p>So, <strong>it looks like whatever I choose, I'll violate some rules</strong>. What's better way then, which should I choose? Maybe there is other approach I haven't found?</p>