| In this chapter we discussed several important real-world topics for developing ADO.NET database applications. Concurrency detection is an important multiuser design considerations, especially when you're working in a disconnected mode with the DataSet. Table and column mappings are a convenience that adds to the readability and maintainability of application code. Using DataView objects offers multiple views of the same data, each with its own filter and sort settings. Finally, the strongly typed DataSet provides the option of advanced functionality and readability, when used in appropriate situations. Questions and Answers | Q1: | Now that I understand how to detect a concurrency violation, how do I resolve it? | | A1: | The answer to this question is application specific. You may decide that, if a concurrency conflict is detected, the user must requery the database and start over. You may decide to let the second user's changes override the first user's changes but write to a log (or send a message) of the occurrence. A third option is to let the user decide, by presenting her with all three sets of data: the original values, the values currently in the database, and the values that she is trying to set in the database. Finally, you could develop an algorithm or some logical code to let the application decide on its own which change to keep. For example, perhaps the priority or role of the user, such as supervisor versus clerk, should be the determining factor. ADO.NET and Visual Studio.NET provide the tools for detecting the concurrency violation you still need to make the hard decisions as to how to resolve it! | | Q2: | Should I always use typed DataSets? If not, what do I need to consider when deciding? | | A2: | As is usually the case, the answer is "It depends." We've shown the advantages of the typed DataSet, but there are still times when using an untyped DataSet is preferable. That's mainly the case when the schemas being loaded into the DataSet are unknown ahead of time or are subject to change. A classic example is queries that are being generated on the fly or are being specified by the user in some type of query builder. Or maybe you want the schema to be specified by the XML file that you're reading. In these cases, you can't provide a schema to generate the typed DataSet during design time. Another consideration or trade-off is whether writing generic procedures is a key requirement of your development project. The benefits of typed DataSets come at the price of nongeneric code. One consequence of using a nongeneric typed DataSet is that any change to the database schema requires a regeneration and recompilation of the typed DataSet objects. Finally, the standard, untyped DataSet object is so useful and easy to use, you may often want to use it to manage data that isn't schema based. An untyped DataSet could be a great alternative to implementing custom data structures with custom search, sort, and filter algorithms. The XML capabilities of the DataSet are an additional free bonus. |
|
