The repeater is the favorable alternative here, not only because it is the generally expected solution for the situation, but also because it allows future developer to tap into the rich event hierarchy of the repeater control.

I'm not sure that the code is business logic.  You will always have some sort of server-side code in your presentation layer, but just because it's code doesn't make it business logic.  The trouble is making sure the actual business logic code is not included in the presentation layer.  But I don't think any feature of a language *prevents* you from architecting/designing badly.

+1 dave.

It's not business logic, it's presentation logic.  One thing I always wonder about is whether putitng a validator on your page is "business logic".  I say no, you should be checking on the form, and in the business layer both.

Event hierarchy I'm referring to the various databinding events you can hook into.

I agree you should check both in UI and BL, although I have seen approaches used where the only validation is done in the BL and a result object is rendered to let the user know if anything went wrong.

This has to be carefully worked into the design, so generally speaking it will work just as well to use validators.

Specific business logic will usually be only found in one page/form thus there's no real benefit gained in trying to make it reusable. And either way, it's pretty easy to make custom validators which can be deployed in many pages (e.g. for postcodes, ph nums, etc.)

Validators in the presentation layer are definitely Business Logic.

That's why they're evil. :-)

If what you accept as valid is different from a WebForm than a WinForm, than a batch processor, then that's business logic. If it's not, then it's just incohesive code. The UnDRY.

It's easy to see how you could take this to a rediculous extreme (and I'm sure someone will try :-) ), but as a general principle...

BTW, Repeaters are code. Xml as Presentation Component is Code with a capital "C". Just because it doesn't have curly braces doesn't mean it's not code. If it's interpreted, if it defines execution flow, if you have to maintain it, it's code.

At least in my book.

...and since the Repeater breaks a major OO design principle (it's high on coupling, low on cohesion), I definitely prefer the no-surprises approach of the foreach loop. It's not like you're going to be slowed down later if you need to replace it after all. To each his own though.