0

The 2 options are: use parameters in aspx files or bind through code-behind. Which is better and why?

p.campbell
  • 98,673
  • 67
  • 256
  • 322
user194076
  • 8,787
  • 23
  • 94
  • 154

2 Answers2

2

I recommend using ObjectDataSource because it leads to a cleaner architecture and is much easier to deal with events, e.g., sorting and paging. Otherwise, your control must specifically handle such events, which I find to be a pain in the neck. I always create a business tier and have my Get() methods use signatures like those shown below. My model for this kind of design comes from this book, which I think is a great Web Forms resource:

http://www.amazon.com/ASP-NET-2-0-Website-Programming-Programmer/dp/0764584642

In the app_code / business tier:

public class ProductRepository
{
  public List<Product> GetAll(/* params here */ string sortOrder, string orderBy, int startRowIndex, int maximumRows)
  {
      // call data access tier for Product entities
  }

  public int GetAllCount(/* params here */ )
  {
      // call data access tier for count of Product entities
  }
}

In the Web Form:

<asp:ObjectDataSource ID="objProduct" runat="server"
  TypeName="MyNameSpace.BLL.ProductRepository"
  SelectMethod="GetAll"
  EnablePaging="true" 
  SortParameterName="sortOrder"
  SelectCountMethod="GetAllCount"  />
Brett
  • 8,575
  • 5
  • 38
  • 51
  • How could I use a DataSource to read from an Object instead of a Database? – Yuri Ghensev Oct 26 '11 at 15:21
  • I assume you mean "ObjectDataSource". I sometimes do this when I'm mocking things up and there's no DB yet. All you do is hard-code the list in the object. In the above example, you would add a member variable, "private List allProducts = null;". In the constructor (or factory method), you would populate "allProducts" with the products., e.g., "allProducts.Add(new Product{});" – Brett Oct 26 '11 at 15:52
-1

The principle of less code. Place as much as possible in the aspx file.

Kevin Coulombe
  • 1,517
  • 1
  • 17
  • 35
  • Would you rather that the aspx know too much things lower down or that the code behind control too much on the UI... You can't apply it without discrimination, but I think dragging stuff in the UI is often better than dragging them into the code-behind. – Kevin Coulombe Jun 29 '11 at 21:28
  • I'm all for declarative abstraction in the UI but things like Razor really rub me the wrong way because logic has no place in the UI layer. – IrishChieftain Jun 29 '11 at 21:33
  • Maybe I'm the one missing the point, but I don't think of data binding as poluting the UI with logic... Actually, even the code behind isn't logic as is but only translation from UI to data and logic. The code behind is just a way of making data binding work when the aspx can't do it. Your logic should be hidden away in a separate layer, not in the code behind. And this is all in line with having less code since you may reuse your data/logic layer some other way. – Kevin Coulombe Jul 06 '11 at 20:47