views:

184

answers:

2

So my question is more in relation to what people consider to be the best practice and why:

I've been dropping literals into pages and repeaters and binding them in code behind for a while. Is this considered bad practice? ie:

ASPX Page:

<asp: Literal id="litTextToInsert" runat="Server" />

Code Behind:

litTextToInsert.Text = objData.MyText;

OR (repeater):

protected void rpt_ItemDataBoundVersion(object sender, RepeaterItemEventArgs e)
{
    if (e.Item.ItemType == ListItemType.Item || e.Item.ItemType == ListItemType.AlternatingItem)
    {
        RepeaterItem objItem = e.Item;
        Data.MyObject objDataItem = (Data.MyObject) objItem.DataItem;
        Literal litMyText= (Literal)objItem.FindControl("litTextToInsert");
        litMyText = objDataItem.MyText;               
    }
}

With most demos about MVC and general WebForms i see a lot of people simply dropping binding code into the front end

ie:

ASPX Page:

<%#Eval("MyText") %>

I personally dont like doing this as i find it makes it harder for me to know if someone changed the field name, or mis typed it during development - the other way you won't know until the page loads.

With the strongly typed version if something changes in your DAL etc the build will break - letting me know I've messed up.

Why do so many people appear to use weakly typed code in ASP.Net (in examples, MVC, etc)? Am i missing something? Am i an idiot and missing the point? Is this just because its demo code attempting to be simpler?

Let me know.

+1  A: 

You are right in saying that using binding expressions on the .aspx page means that you will not get compile time warnings for incorrect syntax/usage. You can see this as a weakness or a strength.

Binding expressions on the .aspx page:

  • Allow you to change your .aspx without recompiling and redeploying.
  • You can add/change binding expressions on the fly
  • Reduce code behind clutter
  • Are weakly typed
  • Keep display logic where it belongs

Similarly, biding on the code behind:

  • Makes sure your codebase is cohesive (.aspx pages will not diverge)
  • Strongly typed
  • Static code analysis will work better

I am sure others will come up with many other examples for and against either option.

In my opinion - you should use what you are comfortable with. Some people use binding expressions exclusively in their .aspx pages with a large object graph being bound and it works great for them. Others will make sure they only ever do so in the code behind file, and it works great for them too.

Oded
+1  A: 

In "normal" aspx pages, binding is not type save and you will not get compile time errors, as Oded said. However, in MVC this is another cup, here you get compile time warnings and erros and even intellisense.

In "normal" aspx pages the events are handled in a code behind page that needs to be integrated with the aspx page. In MVC the events are handled by the controller and the view can be seen as "just a template", much like in classic ASP. The big advantage over classic ASP is, however, the extended design and compile time support.

Obalix
This is great - i never thought about the compile time support in MVC as i've never noticed it... will try and break it to test when i work on an MVC proj this arvo...
Doug
Does anyone know which build servers support MVC view verification?
Doug