Top of the list is the ASP.NET Futures release which is now available for download. The new Media Control
is particularly helpful because up to now many developers had to
purchase third party controls to present video in websites. The Browser
History and Back Button Support
is also being addressed for those of you interested in Ajax. This is an
early developer preview, so you may not want to install it on your main
Speaking of Ajax, be sure to check out the new ASP.NET Ajax Control Toolkit as well as a host of new instructional videos and articles.
The new ASP.Net RSS Toolkit Version 2 has been released and enables ASP.NET applications to consume and publish RSS feeds. [More]
Some new tutorials have been added to ASP.NET Data Tutorials series.
Last but not least, get an early look at Visual Studio 2008
(aka Orcas). The official release of the 2008 line of products (Visual
Studio 2008, Windows Server 2008 and SQL Server 2008) will be in Las
Vegas next February.
I'm not trying to re-ignite this age-old debate but am merely using it as a starting point to
explore the data access options available to date and where we may be heading in the near
future. In the next post, I will look at multi-tier design and the use of custom
entity class objects. Later on, we may look at that new animal called LINQ. I recommend the following as an introduction to ADO.NET:
Best Practises for Using ADO.NET
Working with Data in ASP.NET 2.0
Many programmers mistakenly view the DataSet as the only real option
for data access as far as Web applications are concerned. We often
choose between DataReader and DataSet based either on our familiarity
with the syntax of one over the other or our lack of understanding of
the basic differences between them. More often than not, we usually end
up using the wrong data access method for the wrong reasons. People
typically see it as a simple choice: the DataReader for speed and the
DataSet for data manipulation. In reality, the choice involves a whole
range of trade-offs. As an overview, here are the basic characteristics
of the both DataReader and the DataSet:
* Forward-only, read-only access
* One row at a time is stored in memory and either written over or discarded
* Light on resources such as IIS
* Cannot be persisted to cache or session
* Holds on to the data connection
* Can navigate backwards and forwards
* Stores all data in memory
* More intense use of IIS and memory resources
* Connections closed immediately the data is gathered
* Relational-data-aware; can consist of collections of related tables
* Can make updates back to the database
* Data can be stored in session
Things We Tend to Forget:
* To close the DataReader and/or Connection
* Data-bound controls keep their own copy of any data to which they are bound
* To use the DataReader's HasRows and IsDBNull properties to avoid errors
* To use the DataReader for simple data-binding where no caching of data is necessary
* With DataSets, primary keys and relationships have to be re-created in code
* DataSets support data transactions and data filtering
* Unlike DataReaders, DataSets support binding to multiple controls
* DataSets can be used to manipulate the data as XML
If there is one lesson to be learned here, it is not to make snap
decisions when it comes to choosing between these two data access
models. You need to think it through each and every time you are
accessing the database and binding to a control. The DataReader may be
fast but it doesn't support binding to multiple controls. So, you won't
gain much mileage from trying to use it to sort and filter with rich
controls. The DataSet is particularly useful when used to
intermittently connect to the database as with salespeople on the road.
The data can be serialized to XML and stored offline.
I mentioned that data-bound controls keep their own copy of the data
to which they are bound: by my calculations, that makes for three
distinct copies of the data when using a DataSet; any questions?!!
One of the most common features of community websites these days is the events calendar. It's also the source of one of my pet hates, the stretching of calendar cells as event title links are added for a particular day. Nothing looks worse than an event calendar with an average of one or two events per day... with that one fifteen-event day stretching the entire Calendar control down the page. This is not just an issue of esthetics. If you only display a limited number of events for a given day, pretty soon the other event organizers will be calling to ask why their events are not being shown! In such situations, a compromise is frequently called for.
Recently, I worked on such an events calendar for my local town's Business Improvement District. The client wanted an easy way for users to see when there were events without having to dig too much to find them.I did not want to use the Calendar control to display event links. I chose instead to implement a master Calendar highlighting days that had events, and an associated events listing implemented as a pageable GridView.
During development, I encountered the following exception:
ObjectDataSource 'sourceEvents' could not find a non-generic method 'GetEventsByMonth' that has parameters: startDate, endDate, startDate1, endDate1...
This occurred in the paging event handler for the GridView. I was adding the SQL parameters programmatically and implemented a quick fix as shown below:
// Manually remove any select parameters from ParameterCollection sourceEvents.SelectParameters.Remove(sourceEvents.SelectParameters["startDate"]); sourceEvents.SelectParameters.Remove(sourceEvents.SelectParameters["endDate"]);
Then I added the same parameters as before and everything worked fine.
If I ever have to do something similar again and there are a lot of events involved, I might have to look to AJAX for a more creative alternative. Has anyone found another way of doing this? If you would like the complete code, please email me.