Jeff Perrin - Sexier Than You Are

Thoughts on Code in ASPX Pages

This post was inspired by a comment I saw on another person's blog (which I couldn't find for the life of me, so no linky for them). The comment was in regards to Ruby on Rails use of pure ruby code in the .rhtml view files, and how this was seen as a bad thing. I've written a similar post on my personal blog but I thought my point was worth bringing up again.

How many of you faithful devlicio.us readers would cringe at the sight of the following code snippet embedded within an aspx page?

	<% foreach( Item item in LineItems ){ %>
	    <p> <%= item.Name %> </p>
	<% } %>

On first glance, it looks bad because sometime in the past we were told that embedding business logic in the view is bad. But I'd urge you to look again. Is there actually any business logic in the above snippet? There's none, actually. We're just iterating over a list of Items and printing a property out to the rendered markup. We could accomplish the same thing with a repeater like so:

	
	<asp:Repeater id="repeater" runat="server">
	    <itemtemplate>
	        <p><%# Eval("Name") %>
	    </itemtemplate>
	</asp:Repeater>

Which one is easier to read? It's pretty subjective... The repeater declaration happens to look just like html or xml markup, so it blends in nicely with any other markup that may appear in our page. This blending can be seen as a good thing, or a bad thing if you like to be able to instantly see any dynamic stuff at a glance. The problem with repeaters it can be hard to see exactly what you're iterating over without also looking into the code-behind. The plus side is that you get nice support for alternating item templates, which can quickly make an embedded foreach look ugly.

The real question is, does using a control like the repeater prevent you from sticking business logic in your views? The answer is no, it doesn't.

Just something to think about.

Published Oct 25 2006, 06:50 PM by Jeff Perrin

Comments

Eric Wise said:

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.

# October 25, 2006 9:23 PM

Jeff Perrin said:

Eric, I don't disagree that the repeater is most likely the best way to go. In fact, it's by *far* the control I use most. The point of my post is that you *can* embed inline code in the view *without* embedding business logic.

As for using the event hierarchy of the repeater... Could you elaborate?

# October 25, 2006 9:43 PM

dave thieben said:

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.

# October 26, 2006 1:34 PM

Eric Wise said:

+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.

# October 27, 2006 10:59 PM

Joe Niland said:

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.)

# October 28, 2006 7:43 AM

Jeff Perrin said:

I'm not sure if I successfully got my point across. I was trying to show two functionally equivalent pieces of code, the first one using inline C#, the second using the standard ASP.NET template language. Either one is fine, it's just a matter of taste as to which one we use.

The comment this post is an indirect reply to implied that using pure ruby as a templating language was bad because putting business logic in the UI is bad. I've heard this before in the .NET world as well. My point is that the choice of templating language is completely separate from whether or not you have stuff in your UI layer that shouldn't be there.

# October 28, 2006 10:34 AM

Sam Smoot said:

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.

# October 30, 2006 11:43 PM

About Jeff Perrin

Jeff is not an internationally (or even locally) known expert in anything related to software development. He holds no certifications worth speaking about, and didn't graduate from University. The value of anything written on his blog should be deemed suspect at the minimum, and blatantly false and misleading in the worst case. Don't let his innate sex appeal fool you... Jeff does not know anything about which he speaks.