The SqlDataSource control enables you to use a Web control to access data located in a relational data base, including Microsoft SQL Server and Oracle databases, as well as OLE DB and ODBC data sources. You can use the SqlDataSource control with other controls that display data, such as the GridView, FormView, and DetailsView controls, to display and manipulate data on an ASP.NET Web page, using little or no code.
The SqlDataSource control uses ADO.NET classes to interact with any database supported by ADO.NET. This includes Microsoft SQL Server (using the System.Data.SqlClient provider), System.Data.OleDb, System.Data.Odbc, and Oracle (using the System.Data.OracleClient provider). Using a SqlDataSource control allows you to access and manipulate data in an ASP.NET page without using ADO.NET classes directly. You provide a connection string to connect to your database and define the SQL statements or stored procedures that work with your data. At run time, the SqlDataSource control automatically opens the database connection, executes the SQL statement or stored procedure, returns the selected data (if any), and then closes the connection.
The ASP.NET ObjectDataSource control represents a middle-tier object with data retrieval and update capabilities. The ObjectDataSource control acts as a data interface for data-bound controls such as the GridView, FormView, or DetailsView controls. You can use these controls to display and edit data from a middle-tier business object on an ASP.NET Web page.
The ObjectDataSource control uses reflection to call methods of a business object to select, update, insert, and delete data. You set the ObjectDataSource control's TypeName property to specify the name of the class to use as a source object. For details on how to create a source data object to be used with the ObjectDataSource control, see Creating an ObjectDataSource Control Source Object.
Sorting and Paging
The ObjectDataSource control can support additional sorting and paging capabilities by passing sort and page information in requests from a data-bound control, such as a GridView control, to the data object for processing. The source data object or the data source control itself can then sort data and return data in pages.
For information on passing sorting and paging parameters to an ObjectDataSource control's data object, see Using Parameters with the ObjectDataSource Control.
Caching
The ObjectDataSource control can cache objects returned by the underlying business object. However, you should not cache objects that hold resources or that maintain state that cannot be shared among multiple requests, such as an open DataReader object.
Filtering
If the object returned to the ObjectDataSource control by the source data object is a DataSet or DataTable object, the ObjectDataSource control supports filtering using the syntax of the Expression property of the DataColumn class. Filtering enables you to expose only rows that match particular search criteria, without having to re-query the data source with new selection criteria. For more information, see Filtering Data Using Data Source Controls.
Conflict Detection
By setting the ObjectDataSource control's ConflictDetection property to true, you can specify that the ObjectDataSource control should include original values when calling update methods of the source data object. The original values can then be included in checks for optimistic concurrency. For more information, see Using Parameters with the ObjectDataSource Control. For information on optimistic concurrency checking, see Optimistic Concurrency (ADO.NET).
Each has its own merits and demerits...If using SQL Server as backend SqlDataSource is much preferable
The SqlDataSource control uses ADO.NET classes to interact with any database supported by ADO.NET. This includes Microsoft SQL Server (using the System.Data.SqlClient provider), System.Data.OleDb, System.Data.Odbc, and Oracle (using the System.Data.OracleClient provider). Using a SqlDataSource control allows you to access and manipulate data in an ASP.NET page without using ADO.NET classes directly. You provide a connection string to connect to your database and define the SQL statements or stored procedures that work with your data. At run time, the SqlDataSource control automatically opens the database connection, executes the SQL statement or stored procedure, returns the selected data (if any), and then closes the connection.
The ASP.NET ObjectDataSource control represents a middle-tier object with data retrieval and update capabilities. The ObjectDataSource control acts as a data interface for data-bound controls such as the GridView, FormView, or DetailsView controls. You can use these controls to display and edit data from a middle-tier business object on an ASP.NET Web page.
The ObjectDataSource control uses reflection to call methods of a business object to select, update, insert, and delete data. You set the ObjectDataSource control's TypeName property to specify the name of the class to use as a source object. For details on how to create a source data object to be used with the ObjectDataSource control, see Creating an ObjectDataSource Control Source Object.
Sorting and Paging
The ObjectDataSource control can support additional sorting and paging capabilities by passing sort and page information in requests from a data-bound control, such as a GridView control, to the data object for processing. The source data object or the data source control itself can then sort data and return data in pages.
For information on passing sorting and paging parameters to an ObjectDataSource control's data object, see Using Parameters with the ObjectDataSource Control.
Caching
The ObjectDataSource control can cache objects returned by the underlying business object. However, you should not cache objects that hold resources or that maintain state that cannot be shared among multiple requests, such as an open DataReader object.
Filtering
If the object returned to the ObjectDataSource control by the source data object is a DataSet or DataTable object, the ObjectDataSource control supports filtering using the syntax of the Expression property of the DataColumn class. Filtering enables you to expose only rows that match particular search criteria, without having to re-query the data source with new selection criteria. For more information, see Filtering Data Using Data Source Controls.
Conflict Detection
By setting the ObjectDataSource control's ConflictDetection property to true, you can specify that the ObjectDataSource control should include original values when calling update methods of the source data object. The original values can then be included in checks for optimistic concurrency. For more information, see Using Parameters with the ObjectDataSource Control. For information on optimistic concurrency checking, see Optimistic Concurrency (ADO.NET).
Each has its own merits and demerits...If using SQL Server as backend SqlDataSource is much preferable
* Type Name
For ObjectDataSource, the property TypeName includes the class name, that will responsible to manage data, this may NOT be the data object collection. The select, insert etc methods will use the mentioned methods to access or retrieve data. For SqlDataSource, a built-in data collection is used, which can be bound to data data controls.
For ObjectDataSource, the property TypeName includes the class name, that will responsible to manage data, this may NOT be the data object collection. The select, insert etc methods will use the mentioned methods to access or retrieve data. For SqlDataSource, a built-in data collection is used, which can be bound to data data controls.
* Connection String
For ObjectDataSource, there is NO connection string needed, as it is used middle tier. For SqlDataSource, connection string is needed.
For ObjectDataSource, there is NO connection string needed, as it is used middle tier. For SqlDataSource, connection string is needed.
* CRUD Method
For ObjectDataSource, there is NO method (select, insert etc) type, as the methods are being used from a class of middle tier. For SqlDataSource, there are two types of methods StoredProcedure and Text. note, in SqlDataSource, for parameters, in the execution time the system automatically includes a '@' before the name as specified in the name property.
DataSources in general and ObjectDataSources in particular are a new feature within ASP.NET 2.0.
At first glance ObjectDataSources raise the expectation that this is a means to support layered architectures that feature a cleanly separated business layer (consisting of business services that exchange business data – either plain class structures or data sets). But this hope dies very fast.
At second glance they appear to support layered architectures that feature data objects (classes that represent the domain specific data model and implement a part of the business interfaces – all in one package). This hope lives longer before it, too, diminishes.
Finally one has to accept that they support about the same conceptual features that a SqlDataSource with DataSets supports: A view into the data that works best if it is closely tied to the current page.
Once you have accepted that you can start thinking about what ObjectDataSources actually can do for you – which is more than this introduction may suggest.
To understand what ObjectDataSources can and cannot do, let’s start with understanding SqlDataSources. On a page you may have a SqlDataSource configured to provide data for your grid view. Thus it would contain a SELECT statement asking for the columns you would like to show and upon databinding of the grid it would issue that statement against the database. Another SqlDataSource an the same page may be configured to select a distinct row, e.g. the one selected within the gridview, to be used by a form view (i.e. providing a master/detail page). This data source would contain a SELECT statement asking for the columns you would like to show/edit (perhaps different columns than in the grid view) and adding a WHERE clause for the id. It also would contain respective UPDATE, INSERT, and DELETE statements. The word “contain” in this context means “buried into the page”, as in this excerpt:
<asp:SqlDataSource ID=”SqlDataSource2″ runat=”server” ConnectionString=”<%$ ConnectionStrings:ConnectionString %>“
SelectCommand=”SELECT * FROM [Authors] WHERE ([Id] = @Id)”
UpdateCommand=”UPDATE [Authors] SET [fname] = @fname, [lname] = @lname, [phone] = @phone WHERE [Id] = @Id”>
<SelectParameters>
<asp:ControlParameter ControlID=”GridView1″ Name=”Id” PropertyName=”SelectedValue” Type=”Object” />
SelectParameters>
<UpdateParameters>
<asp:Parameter Name=”fname” Type=”String” />
<asp:Parameter Name=”lname” Type=”String” />
<asp:Parameter Name=”phone” Type=”String” />
<asp:Parameter Name=”Id” Type=”Object” />
UpdateParameters>
[...]
asp:SqlDataSource>
Let’s make that clear: Every databound control (grid view and form view in our example) has its own private datasource control. This means in particular:
Now, this is crucial for the understanding and the implications are both good and bad.
For not so small, non-trivial, or enterprise applications, e.g.
ObjectDataSource in its plain form may not be the way to go either. Yet it offers the extensibility to roll your own additional logic. The farther you deviate from vanilla web applications, the more work you have to do – but you can do it.
Ergo: Use the right tool for the job at hand and know how to handle the tool. ObjectDataSource is a good tool if you know when to use it, how to use it, and what not to expect.
That’s all for now folks,
For ObjectDataSource, there is NO method (select, insert etc) type, as the methods are being used from a class of middle tier. For SqlDataSource, there are two types of methods StoredProcedure and Text. note, in SqlDataSource, for parameters, in the execution time the system automatically includes a '@' before the name as specified in the name property.
DataSources in general and ObjectDataSources in particular are a new feature within ASP.NET 2.0.
At first glance ObjectDataSources raise the expectation that this is a means to support layered architectures that feature a cleanly separated business layer (consisting of business services that exchange business data – either plain class structures or data sets). But this hope dies very fast.
At second glance they appear to support layered architectures that feature data objects (classes that represent the domain specific data model and implement a part of the business interfaces – all in one package). This hope lives longer before it, too, diminishes.
Finally one has to accept that they support about the same conceptual features that a SqlDataSource with DataSets supports: A view into the data that works best if it is closely tied to the current page.
Once you have accepted that you can start thinking about what ObjectDataSources actually can do for you – which is more than this introduction may suggest.
To understand what ObjectDataSources can and cannot do, let’s start with understanding SqlDataSources. On a page you may have a SqlDataSource configured to provide data for your grid view. Thus it would contain a SELECT statement asking for the columns you would like to show and upon databinding of the grid it would issue that statement against the database. Another SqlDataSource an the same page may be configured to select a distinct row, e.g. the one selected within the gridview, to be used by a form view (i.e. providing a master/detail page). This data source would contain a SELECT statement asking for the columns you would like to show/edit (perhaps different columns than in the grid view) and adding a WHERE clause for the id. It also would contain respective UPDATE, INSERT, and DELETE statements. The word “contain” in this context means “buried into the page”, as in this excerpt:
<asp:SqlDataSource ID=”SqlDataSource2″ runat=”server” ConnectionString=”<%$ ConnectionStrings:ConnectionString %>“
SelectCommand=”SELECT * FROM [Authors] WHERE ([Id] = @Id)”
UpdateCommand=”UPDATE [Authors] SET [fname] = @fname, [lname] = @lname, [phone] = @phone WHERE [Id] = @Id”>
<SelectParameters>
<asp:ControlParameter ControlID=”GridView1″ Name=”Id” PropertyName=”SelectedValue” Type=”Object” />
SelectParameters>
<UpdateParameters>
<asp:Parameter Name=”fname” Type=”String” />
<asp:Parameter Name=”lname” Type=”String” />
<asp:Parameter Name=”phone” Type=”String” />
<asp:Parameter Name=”Id” Type=”Object” />
UpdateParameters>
[...]
asp:SqlDataSource>
Let’s make that clear: Every databound control (grid view and form view in our example) has its own private datasource control. This means in particular:
- The datasource controls are independent of each other, going directly to the database. If one datasource control issues an UPDATE statement the other one will reflect those changes only if its SELECT comes after the UPDATE.
- The datasource controls are tailored to the specific needs of the databound control, i.e. giving access to exacly the data that is shown/manipulated. E.g. if a datasource selected/updated a column “street”, yet this column is not bound within the form view, it will not be left as is on update, rather it will be overwritten with NULL (best case).
Now, this is crucial for the understanding and the implications are both good and bad.
- For one thing, calling a method means abstraction. Having SQL statements within the pages ties the database structures directly into your UI code. A method can hide some of these details.
ObjectDataSource is good!
- C# classes are indivisible. While a SQL statement can explicitely state which columns to access, a class cannot be asked to please contain only a subset (i.e. a partition) of its properties. (Well, not unless we have LINQ support.) Thus we cannot use class instances for insert or update methods if we are only working on a partition of that object. In these cases we will have to provide methods like UpdateMainData(Customer), UpdateAddress(Customer), UpdateContactData(Customer), … with the name implying the partition of the Customer data type (or conceptually equal methods with single field parameters rather than customer objects). Can you spell “maintenance”?
- ObjectDataSources create the configured data object class on demand, each datasource its own data object. Again, those data objects know nothing of each other, no change yet.
- However, there is the possibility to subscribe to certain events and customize the behaviour. One could register for the ObjectCreating event and rather than creating a new data object return a reference to a previously created object. One could also register for the Updating event and implement logic that updates exactly the provided fields.
For not so small, non-trivial, or enterprise applications, e.g.
- consisting of many pages,
- needing more sophisticated business logic,
- having a business logic layer that is (in principle) independent of UI specifics,
- having to comply with database access restrictions/policies,
- requiring a more sophisticated UI, e.g. maintaining changes in state before they are explicitely saved,
- being subject to versioning,
- …
ObjectDataSource in its plain form may not be the way to go either. Yet it offers the extensibility to roll your own additional logic. The farther you deviate from vanilla web applications, the more work you have to do – but you can do it.
Ergo: Use the right tool for the job at hand and know how to handle the tool. ObjectDataSource is a good tool if you know when to use it, how to use it, and what not to expect.
That’s all for now folks,
No comments:
Post a Comment