One of the most important (if not the most important) when assembling a management application is the technique used to link the application with the database.
In the past the type of database used to store persistent data in our application was crucial and should be carefully chosen before starting to transform the project into code. Since Visual Studio. Net appeared that choice is no longer crucial, data adapters and the ability to handle tables "disconnected" has allowed us to separate easily the data layer of application logic, which in turn facilitates the migration of a database type to another , keeping intact most of the coding of our project.
While the type of database used is not as critical, the latest versions of Visual Studio we offer a wide range of options (DataSets, LINQ to SQL, Entity Framework, etc.) When you connect your application with this database, which generates a myriad of doubts about which one is the best and we should use. Well, try this article shed some light to dispel those doubts, but always from my experience as a developer, trying to offer, not a guide, but a help.
What is the best technique for databinding (DataBinding): No there is a direct response to this question. Everything depends on the context in which they will use that link and functions that will in each case (read-only or edit).
begin by describing the main technical liaison and their qualities and drawbacks:
- DataAdapter and DataSet . Born with Visual Studio. Net and are a big leap from ADO or DAO that integrated Visual Studio 6.0. Provide the ability to manipulate data in a disconnected (loaded in memory) and are easy to implement. Currently in disuse since version 2.0. Net Framework was introduced following our protagonists:
- Typed DataSet. It is a combination of the previous two into a single entity, with the possibility of extending its functionality with our own code. Much easier to implement and is much more powerful.
- DataReader. Only allows sequential reading of records from the database. By itself not a data-binding method, but makes it easy. In fact it is the technique used the TableAdapter to fill a DataSet with data. Notwithstanding expose a binding method because in the case of collection of reports (read-only data) may be a good option to consider.
- LINQ to SQL. Based on the data query language introduced in version 3.5. NET Framework and classes such as containers for data, allows for bidirectional data link is disconnected (like DataSet). The effectiveness and intelligence with which manages the reads and writes to the database get a spectacular performance. At the same time, the power of language integrated query (LINQ) allows the extraction of data very flexible and convenient for programmer. As a limitation we say that only allows connection to SQL Server, yes, in all its editions.
- LINQ to Entities. Combines language integrated query (LINQ) with Entity Framework . Basically the same as LINQ to SQL but allows us to connect to any other database through OLEDB.
The most appropriate in each case will depend on several factors. Among them is the purpose of the link to conduct (maintenance of data, running processes, mining reports and graphs, etc..), The speed connection to the database, etc ...
The technique offers the best speed reading of data is the use of DataReaders . Sequentially read records one by one and simply return the read data as we are going begging. On the other hand, requires more lines of code to process, given that we index the fields returned (with an Enum, for example) to access their values. We also need to take care of converting the type of information obtained if necessary. In summary: high speed processing, but more lines of code to write. It would be the best choice for reading a large amount of data (tens of thousands of records), with poor connection speed (databases on the Internet) or in very long process where We often repeat the readings. Obviously if we need to update the data read from the database will have to use Command objects .
DataSets allow us a full link (inserts, updates and deletes). Are based on a SQL SELECT command and the designer of Visual Studio we automatically generates INSERT, UPDATE and DELETE. Loaded into memory read data, allows for modification in memory and the writing of these amendments as soon as we decide, maintaining the integrity of the changes from other users in the database. We save many lines of code (which automatically generates the designer), and have a very acceptable performance. Is an optimal choice for maintenance of data tables, and almost the only if our assembly only runs on version 2.0. Net Framework. In my experience, when a DataSet contains too many tables, the designer is too slow, which makes us lose a little patience.
LINQ (to SQL and to Entities) for me is the option that replaces the DataSet (if we can use version 3.5 or higher. Net Framework) for these reasons:
- offer the same functionality (reading, handling disconnected and writing). Well, almost all functionality. it integrates natively provider errors (those red exclamation marks that appear in the DataGrid when there is some wrong information.) However, it can easily be implemented by inheritance .
- similar or superior performance. In some very specific cases (queries with one or two fields in the result) has been faster the DataSet, but it is generally the opposite. In addition, we can build LINQ queries, speeding execution.
- Low dependence on the type of database. No need to write a single SQL query against the database, because LINQ operates on tables, not queries. The queries are performed then LINQ to read data from tables. This has the advantage that it need not be expert programmers to SQL Server or Oracle. At the same time offloads the server from the database, it does not handle complex queries. Facilisimo
- implementation. Simply drag the tables to the designer file. Dbml or. Edmx and already created the class with all the fields ready to be consulted. Then we can create associations between tables and we have one-to-many or one to one available in the properties of the classes.
- Very easy to extend. By Partial Class can provide our own methods or properties to a table. Unlike the DataSet, when we create a property in code (which does not correspond to a field in the table), this is linked directly to a Windows Forms control.
Conclusion: DataReader
- : Use only in situations read-only where performance is critical.
- DataSet : Use only if your application does not run. Net Framework 3.5 or later or we will make a link to XML files. LINQ
- : Use in other cases.
0 comments:
Post a Comment