Summary

In this chapter, we examined the universal language of data exchange in .NET: ADO.NET providers and the DataSet. We also covered the basic architecture of and best practices for stored procedures and transactions. You also learned about a key design decision: whether to use custom objects or the DataSet. Finally, we took a realistic look at the drawbacks to and benefits of the DataSet.

It's important to remember that Microsoft's own designs tend to favor simple classes and structures over the DataSet, and that DataSet-based updates introduce additional headaches that might require far more effort than they are worth. Ultimately, the ideal niche for DataSet use may be in cross-platform programming, where its seamless XML conversion allows any client to retrieve and process the results of a query.

For more examples of information package and service provider classes that use ADO.NET code, refer to the case studies at the end of this book. All three case studies use data components as part of the solution.