Contents tagged with ASP.Net

  • List<t> paging via LINQ to Objects

    The various grid controls shipped with asp.net provides plug and play data paging on its underlying data source. Its quiet simple to get a paged view of your data by setting a few properties on the grid before calling the Bind() method to connect your grid to the data.  This scenario works well in most situations. On occasions where the paging logic needs to reside outside of the UI layer, a more custom paging mechanism is required.

  • Options for Database access outside of ADO.Net

    In the world of .NET programming, ADO.NET has become the De Facto standard for accessing database of all types (relational or otherwise). The purists among us will be quick to point out that ADO.Net should be the only option and that as developers we shouldn’t even be thinking about bypassing ADO.NET to get to our database. But the no-so-pure will be quick to point out the alternative methods for pulling data from our databases without writing a line of database code. If you are still reading this article, it means you, like your truly have had occasions in the past where bypassing ADO.Net makes sense, whether you are creating a small website for your wedding guest list, or just putting together a demo website of sorts.

    The SqlDataSource Control:
    The SqlDataSource control (in my mind, the grand-daddy of declarative data Access) allows for the definition of queries in a declarative way. You can connect the SqlDataSource to controls such as the Datalist, and give your users the option to edit and update data without requiring any ADO.NET code.  While the sqlDatasource control handles the heavy lifting required to facilitate the communication, it's worth mentioning that behind the scenes, it uses ADO.NET to do this heavy-lifting. The sqlDatasource supports any database that has a full ADO.NET provider. Apart from the fact that the sqlDatasource connects you to your database with minimal code, it does provide more benefits to developers who are looking to provide functionality such as paging sorting of datagrids without having to write lines of code to achieve this. If you bind your datagrid directly to a sqlDatasource control, you have paging and sorting functionality right at your fingertips.  You can get to it by setting a few properties on your grid control. However, with all its "niceties" the SqlDataSource is somewhat controversial, because it encourages you to place database logic in the markup portion of your page. Many will agree that there are times when the benefits of using this control far outweigh this particular drawback.

    LINQ to SQL:
    Linq provides us with cool new way of accessing data.  The source of this data can range from anything from files in your computer file system, a collection of objects living in a generic list in server memory, or rows of data residing in a database table in on the North Pole. Linq comes in a variety of flavors (LINQ to objects, LINQ to XML, LINQ to entities, LINQ to SQL, LINQ to Dataset).  With LINQ to SQL, you define a query using C# code (or the LinqDataSource control) and the appropriate database logic is generated automatically. LINQ to SQL supports updates, generates secure and well-written SQL statements, and provides some customizability. Like the SQLDataSource control, LINQ to SQL doesn’t allow you to execute database commands that don’t map to straightforward queries and updates
    (such as creating tables). Unlike the SqlDataSource control, LINQ to SQL only works with SQL Server and is completely independent of ADO.NET.

    Profiles:
    The profiles feature, introduced in .Net Framework 2.0, allows you to store user-specific blocks of data in a database without writing
    ADO.NET code.  You specify what data you want to gather and store by configuring the appropriate elements in your applications configuration file.

  • Enhance your apps with the Integrated ASP.Net Pipleline

    The January publication of MSDN Magazine carried an article titled "Enhance your apps with Integrated ASP.Net Pipleline". While the subject of the article is not something that I would normally be super excited about, I decidede to spend at least 10 minutes perusing the article while commuting to work this morning (Been riding the train past couple of weeks).  I recently installed Vista on my Notebook, and was keen to start looking into the features of IIS 7.0, which ships with microsoft's latest desktop operating system.  As it turned out, the article touched on a subject that might be useful down the road as we take a leap into the world of PHP programming at work.

    Its long been common knowledge that PHP could run under IIS, but not in a way that would make it feasible to run production apps...in other words, if you configure your PHP apps in IIS 6.0/5.0, the result would be a web site that runs very slow, if nothing else, due mainly to the lack of thread safety in PHP apps. Alternately, the app could be configured to run under IIS using CGI, but CGI is a resource hog (one process per request) and results in an app that scale poorly in IIS.