Why Repeaters in ASP.NET?

Question

I'm a Ruby on Rails / PHP guy, and my company got me to work with ASP.NET. It's not too bad, I'm glad to learn a new language but since I started working with this technology everyone is bothering me about Repeaters.

The thing is that I totally fail of seeing the point: what make using a repeater better than just displaying things in a loop? Am I going to programmers' hell for this?

In rails I would do...

controller

@types= Type.find(:all)

view

 <%@types.each do |t| %>
  <%= t.name %> <%= link_to "view", t%>
 <%end%>

In ASP.NET I'd do:

controller class attributes

protected List<Type> _types = null;

controller class PageLoad

_types = MethodThatGetTypeFromDB();

view

<% foreach (var tin _types){%>
   <%= t.name %>
<%}%>

There are no repeaters, but the code is clean, DRY and respects the MVC AP. I don't create methods everywhere to handle ItemDataBound or whatever. So what's the idea here? Am I the only one that find that repeaters are a pain to set up and are not worth it compared to the advantages they bring?

I think I'm just not getting the idea here.

I'm not trying to start a battle rails vs the world, it's just that this is what I know the best so this is the paradigm I'm trying to find when I'm developing. I think it's more convenient and I'm used to it, but if someone goes "Repeaters are good because A, B and C, doing what you're doing is terrible because D, E and F", then I'll admit it and change my approach.

Answer 1

I think the thing you will find with ASP.NET Web Controls is that they provide lots of infrastructure.

For your use case, a for loop may be perfectly fine.

But for more complicated formatting problems and development practices, it could be beneficial to have an object (the Repeater) wrap up all the functionality of your for loop and provide tons of extra features in a code-behind, Intellisense-enabled fashion.

Answer 2

Repeaters fit nicely into the code-behind approach. I spent many years where I couldn't stand the sight of any code in the markup. All code belonged in the code-behind separated from the markup. This was largely a reaction to the horrid messes I dealt with in classic ASP.

Now with ASP.Net MVC, I find I'm going back to exactly what you describe above. But, I'm finding it hard to overcome the instinct to keep markup and code separate.

Edit: Here's an article from 2003 about the debate regarding code-behind.

Answer 3

The repeater's main advantage comes when you are generating multiple ASP.NET controls inside of said loops.

But for the majority of its uses, it's just a different way of doing exactly what you're doing.

Answer 4

Well, for one thing, it's considered bad form to use '<% code here %>' overly much in ASP.NET, that's mainly a throwback to the old asp days. It intersperses the code and the display, which makes it harder to read the page.

Thus, if you work from the code-behind, you've got to construct server tags or html tags, assign them dynamically, etc. and you end up with a lot more code than you would have if you had just used a repeater.

Repeaters also make it easier to use .NET's built-in globalization, as much of their text is automatically added to resx files via the 'Generate Local Resource' tool in VS's Design mode. This also avoids the possibility of invalid viewstates caused by the creation of tags on the code-behind.

Edit (in response to comment):

.NET's built-in globalization uses resource (.resx) files to store parts of the page (typically text) such as the page title, tag properties, and anything else that can be globalized.

You then create an additional resx file for each language you support (french would be 'pagename.aspx.fr.resx', spanish would be 'pagename.aspx.es.resx', etc) and .NET will determine the users's browser language at runtime and use strings from the resx files (starting with the most specific it can and degrading down to the default) to replace properties on server tags.

For instance, if you have a server tag with a text of 'Hello', create the resource file (Visual Studio has a tool to do this automatically for you), and have it translated into french, any user to visit your site with their browser language in french will see 'Bonjour' instead.

You'd have to write the code for that by hand if you rolled your own, so if multilingual is a concern with your project, .NET server controls are the way to go.

Answer 5

The reason for the repeaters instead of a loop come down to the basic differences in the coding philosophy. While having a loop in the code certainly wont send you to programmers hell, it just may send you to ASP.NET hell becuase it violates the separation of HTML code and data.

Answer 6

I think the primary aim of repeaters is to keep procedural code out of the view/markup. The idea being that someone who is a graphic/aesthetic designer can come in and change the markup without having to know how to 'code'. Probably of greater concern to you is that lots of people in the .NET world are familiar with the repeater which means it will be easier for them to maintain.

Answer 7

The Asp.Net method of doing web development is different than Rails in that traditional ASP.Net is not MVC based. You can do MVC using traditional ASP.Net;however, it is difficult and clunky (usually). This is what's lead to the ASP.Net MVC framework in order to fill this space.

The repeater was a good control for traditional ASP.net in that it provided better performance and more options than other databound controls. In some cases, it also provided better markup as well. As others have said, it provides a lot of infrastructure as well as a clean separation between mark up and code.

Nothing is really wrong with what you are doing; however, if you're using traditional ASP.Net and not the ASP.Net mvc, the person who maintains the code after you may not be too happy.

Answer 8

1. Code in ASPX is mainly declarative / markup. This typically is easier to maintain especially by members of the team without a strong programming background. Working with markup also helps separate concerns ( e.g. MVC ).

2. If you are using .Net 3.5, I believe Repeaters are largely replaced by ListView.

Answer 9

If you are using asp.net MVC and are told to use a repeater, the person telling you to do that probably is a classic ASP.net person.

In MVC, the only controls you should be using are <asp:ContentPlaceHolder>s and using user controls instead of render :partial => "foo"

Answer 10

Microsoft frequently tries to maximize what you can do without coding. You can do a lot with repeaters without any code-behind. With data source controls you can do a whole lot without any code at all. One can suppose that as a corporate strategy they want to have the easiest-to-use development environment, and "no code at all" is apparently someone's definition of easy to use.

But when you want to move beyond the free automatic behaviors you are knee deep in an event model with lots of twisty passages which all look alike. I am fond of perl's motto, "make the simple things simple and the hard things possible", and Microsoft sometimes seems to prefer "make the simple things trivial and everything else hard".

Some have mentioned that the ASP.Net MVC moves away from this. If true, this is the best news I have heard all day.