Mike Borozdin's Blog

A blog about programming, web and IT in general

Put EntityDataSource Attributes to Code-Behind

The EntityDataSource control is a very powerful one. It allows you to rapidly create database driven application. You don’t have to manually write code for extracting, modification and deleting records from the database. Moreover since this code is backed by Entity Framework, you are not tied up with a particular database schema and can easily change it or even choose other database application.

However when working with EntityDataSource sometimes I feel like I using plain old SqlDataSource and simply have too much unnecessary code in my .aspx files. For instance, you may end up have code like this one:

<asp:EntityDataSource ID="EntityDataSource1" runat="server" 
    ConnectionString="name=NorthwindEntities" 
    DefaultContainerName="NorthwindEntities" EnableDelete="True" 
    EnableInsert="True" EnableUpdate="True" EntitySetName="Products" Include="Categories, Suppliers" AutoGenerateWhereClause="true">
    <WhereParameters>
        <asp:QueryStringParameter Type="Int32" Name="CategoryID" QueryStringField="CategoryID" />
        <asp:QueryStringParameter Type="Int32" Name="SupplierID" QueryStringField="SupplierID" />
    </WhereParameters>
</asp:EntityDataSource>

That certainly isn’t cool at all. Because it simply shouldn’t be in an .aspx file, not only because it breaks application layers, but simply because it inconvenient. It clutters .aspx files which should be templates only. What if a designer meets code like this? What if accidently change something?

Instead it’s reasonable to move all these lines of code to code-behind.

So, in your .aspx file you just leave this declaration:

<asp:EntityDataSource ID="dsProducts" runat="server" />

 

While put all the attribute assignments to code-behind:

NorthwindEntities db = new NorthwindEntities();

dsProducts.ConnectionString = db.Connection.ConnectionString;
dsProducts.DefaultContainerName = "NorthwindEntities";
dsProducts.EntitySetName = "Products";
dsProducts.Include = "Categories, Suppliers";

dsProducts.EnableUpdate = true;
dsProducts.EnableInsert = true;
dsProducts.EnableDelete = true;
dsProducts.AutoGenerateWhereClause = true;

dsProducts.WhereParameters.Add(new QueryStringParameter("CategoryID", TypeCode.Int32, "CategoryID"));
dsProducts.WhereParameters.Add(new QueryStringParameter("SupplierD", TypeCode.Int32, "SupplierID"));

 

In fact, the same technique applies to any other data source control, like LinqDataSource or even ObjectDataSource.


Posted by Mike Borozdin on Monday, March 23, 2009 8:43 AM GMT
  Shout it Kick it!  
Permalink | Comments (6) | Post RSSRSS comment feed

Comments

DotNetKicks.com

Monday, March 23, 2009 8:48 AM GMT

trackback

Trackback from DotNetKicks.com

Put EntityDataSource Attributes to Code-Behind

DotNetShoutout

Monday, March 23, 2009 1:46 PM GMT

trackback

Trackback from DotNetShoutout

Put EntityDataSource Attributes to Code-Behind

The Sky United States

Sunday, April 05, 2009 9:13 AM GMT

The Sky

Yes, I agree... putting too much code on aspx will sometimes confusing when we need to change / add more code.
It's better to put the code behind.

Melayu Boleh United States

Friday, May 08, 2009 2:22 AM GMT

Melayu Boleh

Yes, I agree also make me soo confiuss

PHPlist Web Host United States

Tuesday, May 19, 2009 10:12 PM GMT

PHPlist Web Host

Yeah I understand the point of using strongly-typed datasources.  However, I am in situation where I want to use a view to display information and then use my own insert and update methods to insert/update the data in the view.  So I would need to use either an ObjectDataSource or an EntireDataSource.  As of right now, I just don't see the benefit of using the EntityDataSource over the ObjectDataSource.  So my question is just concerning the comparison of the EntityDataSource vs ObjectDataSource.  Why would one choose to use the EntityDataSource over the ObjectDataSource ?

Mike Borozdin Russia

Wednesday, May 20, 2009 12:41 AM GMT

Mike Borozdin

I use the EntityDataSource control because I use the EntityFramework and I don't have to write code for CRUD operations, they are handled by EntityDataSource.

Comments are closed