<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: ASP.Net 4.0 features</title>
	<atom:link href="http://sorin.serbans.net/blog/index.php/2009/06/26/aspnet-40-features/feed/" rel="self" type="application/rss+xml" />
	<link>http://sorin.serbans.net/blog/index.php/2009/06/26/aspnet-40-features/</link>
	<description>Look at the spoon ... There are no bugs</description>
	<lastBuildDate>Sun, 27 Nov 2011 09:32:30 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
	<item>
		<title>By: Cristian O.</title>
		<link>http://sorin.serbans.net/blog/index.php/2009/06/26/aspnet-40-features/comment-page-1/#comment-4540</link>
		<dc:creator>Cristian O.</dc:creator>
		<pubDate>Fri, 28 Aug 2009 07:16:50 +0000</pubDate>
		<guid isPermaLink="false">http://sorin.serbans.net/blog/?p=113#comment-4540</guid>
		<description>Some features look nice, here&#039;s a personal oppinion:

- Extensible Output Caching
I don&#039;t really think I&#039;ve used output caching. In enterprise applications I&#039;ve always had requirements for the data to be immediately available and the OOTB asp.net caching didn&#039;t fit my needs, that&#039;s why custom caching mechanisms may sound pretty cool. 

- Auto-Start Web Applications
Nice but not that useful

- Client Template Rendering 
Definitely something to consider. I am an adept of using more resources on the client side and use the server only to provide / process data based on rules.

- Instantiating Behaviors and Controls Declaratively
I&#039;m not sure how this affects the page load time (on the client side) if you have many controls on it. We&#039;ll see how this will turn out, right now I&#039;m a bit worried about it.

- Live Data Binding
Definitively useful, this should save a lot of javascript code.

- Using the Observer Pattern with JavaScript Objects and Arrays
Worried about browser performance with more and more code to execute on client side.

- The AdoNetServiceProxy Class 
This seems useless to me, same as ADO.NET Data Services. In a modular enterprise applications, I probably wouldn&#039;t use any of them.

- The DataContext and AdoNetDataContext Classes
How about business rules ? Do we put them in javascript too ?

- Refactoring the Microsoft AJAX Framework Libraries (partial includes)
Definitely useful. There&#039;s no point in laoding js libraries if they are not used.

- Setting Meta Tags with the Page.Keywords and Page.Description Properties
Little value added

- Enabling View State for Individual Controls
Interesting. I hate ViewState, the more control I have on it, the better I feel.

- Routing in ASP.NET 4.0 
Very nice, unfortunately it requires a lot of boring code changes on existing applications

- Setting Client IDs
Well, this is a huge one. Those ctrl01_ucEditEntity_whereTheHellIAm_damnIGotLostAgain_txtName were the most annoying things in the generated HTML (well maybe sometimes the ViewState, but they definitely had a top spot). With libraries like jQuery, javascript development will be nicer.

- Dynamic Data 
No value for me, I never used it and I probably never will.</description>
		<content:encoded><![CDATA[<p>Some features look nice, here&#8217;s a personal oppinion:</p>
<p>- Extensible Output Caching<br />
I don&#8217;t really think I&#8217;ve used output caching. In enterprise applications I&#8217;ve always had requirements for the data to be immediately available and the OOTB asp.net caching didn&#8217;t fit my needs, that&#8217;s why custom caching mechanisms may sound pretty cool. </p>
<p>- Auto-Start Web Applications<br />
Nice but not that useful</p>
<p>- Client Template Rendering<br />
Definitely something to consider. I am an adept of using more resources on the client side and use the server only to provide / process data based on rules.</p>
<p>- Instantiating Behaviors and Controls Declaratively<br />
I&#8217;m not sure how this affects the page load time (on the client side) if you have many controls on it. We&#8217;ll see how this will turn out, right now I&#8217;m a bit worried about it.</p>
<p>- Live Data Binding<br />
Definitively useful, this should save a lot of javascript code.</p>
<p>- Using the Observer Pattern with JavaScript Objects and Arrays<br />
Worried about browser performance with more and more code to execute on client side.</p>
<p>- The AdoNetServiceProxy Class<br />
This seems useless to me, same as ADO.NET Data Services. In a modular enterprise applications, I probably wouldn&#8217;t use any of them.</p>
<p>- The DataContext and AdoNetDataContext Classes<br />
How about business rules ? Do we put them in javascript too ?</p>
<p>- Refactoring the Microsoft AJAX Framework Libraries (partial includes)<br />
Definitely useful. There&#8217;s no point in laoding js libraries if they are not used.</p>
<p>- Setting Meta Tags with the Page.Keywords and Page.Description Properties<br />
Little value added</p>
<p>- Enabling View State for Individual Controls<br />
Interesting. I hate ViewState, the more control I have on it, the better I feel.</p>
<p>- Routing in ASP.NET 4.0<br />
Very nice, unfortunately it requires a lot of boring code changes on existing applications</p>
<p>- Setting Client IDs<br />
Well, this is a huge one. Those ctrl01_ucEditEntity_whereTheHellIAm_damnIGotLostAgain_txtName were the most annoying things in the generated HTML (well maybe sometimes the ViewState, but they definitely had a top spot). With libraries like jQuery, javascript development will be nicer.</p>
<p>- Dynamic Data<br />
No value for me, I never used it and I probably never will.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

