|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 19
Messages: 19
Messages: 19
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
TheServerSide Debates:Learn to love the SqlDataSource Control
I have heard it argued that Microsoft, with the release of its ASP.NET 2.0 Framework, is intent on leading programmers to engage in "bad practices". The charge is directed at the new SqlDataSource control. Unsuspecting programmers, it is claimed, will use the SqlDataSource control and unknowingly commit the unforgivable architectural sin of mixing their user interface, business logic, and data access layers.
The SqlDataSource control enables you to represent a database connection, and common database commands, declaratively. Simply by declaring an instance of the SqlDataSource control in a page, you can represent SELECT, INSERT, UPDATE, and DELETE commands which can be executed against a database.
This new control makes it entirely too easy to display and manipulate database records in a Web page. Without writing a single line of code, you can display and edit database records by using any of the visual data controls such as the new GridView, DetailsView, or FormView controls.
To be precise, there are two reasons that people argue that the SqlDataSource control is evil. First, the SqlDataSource control is a non-visual control. The SqlDataSource control does not, by itself, render any content in a page. Since it is part of the essential nature of a control to have a visual representation, the SqlDataSource is ill-conceived. Really, the SqlDataSource control should have been implemented as a component and not as a control.
The second reason that the SqlDataSource control is considered "really, really bad" is that it encourages programmers to flatten what should be many into one. The SqlDataSource control mixes business logic and data access layers into the user interface layer.
Both of these objections to the SqlDataSource control ignore a fundamental reality: Web site developers want to perform the least amount of work to produce the most result. At the end of the day, the programming framework which enables you to build the best Web application with the least amount of work wins.
The advantage of creating a non-visual control is that the control can be used simply by declaring it on a page. Declaring is almost always easier than coding. If the SqlDataSource control were implemented as a component, then you would need to write some code to instantiate the component and bind it to a visual control on the page.
Furthermore, mixing layers is not always a sin. Architectural theory is valuable only when it makes your life as a programmer easier. For example, building a multi-tier application is a necessity when you need your application to be able to support multiple interfaces (such as both a Web Form interface and a Windows Form interface) or multiple data providers (such as both a Microsoft SQL Server database and an Oracle database). However, there are situations in which building a multi-tier application would be extreme overkill. For example, if you need to build an application which simply consists of a single report page generated from a database, devoting the effort to build a component library would be a tedious waste of time.
In any case, the ASP.NET 2.0 Framework does provide support for building multi-tier applications: the ObjectDataSource control. The ObjectDataSource control enables you to declaratively bind a visual data control, such as a GridView control, directly to a middle-tier business object.
In conclusion, the SqlDataSource control is actually a really good control. It can save you a substantial amount of work and you should not feel bad about taking advantage of it. The ASP.NET Framework dramatically simplifies data access by enabling you to more easily build both single-tier and multi-tier data-driven Web applications.
|
|
|
Message #147930
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Debates:Learn to love the SqlDataSource Control
The SQLDataSource control is not evil in itself, it's how it's being pitched. We're looking at the same situation with this control as we had when .NET 1.0 came out and every demo Microsoft did showed how easy it was to write a web service that returned a Dataset. It has taken literally months for people to realize that Datasets aren't interoperable and therefore aren't appropriate for Web Services. But hey, it made a great demo! How many websites are going to come crashing around a developer's knees before the word gets out that the SqlDataSource control isn't architecturally a good idea?
While we can all agree that a control like the SqlDataSource control is a productivity booster for a web developer who just wants to throw up a quick page, that distinction is not made in most articles and MSDN whitepapers. Therefore, Microsoft is leading developers astray simply by omission of guidance in how to use this control.
Mixing the data layer with the UI is a BAD idea, period. Sure there may be times when you can get away with it, but the eventual unmanageability of it will greatly outweigh the short-term productivity gain. Creating logical layers of abstraction doesn't require physical separation of layers. Just moving the DAL into a separate class is a good idea because it gives you a single place to look for code dealing with the database. In the SqlDataSource scenario, if you change a stored procedure that is used on more than one page, you have to track down every page to make the change. This is bad design incarnate.
Behind the scenes the SqlDataSource control generates the ADO.NET classes (Datasets, SqlCommand, etc.) that is necessary to access the data defined in the control's markup. But what about reuse? If I'm calling a stored procedure with several parameters through a series of page requests, it would be nice to get some reuse from the parameter collection ala Data Access Application Block's parameter caching.
The ObjectDataSource control however does provide an architecturally sound way to bind web page controls to a middle-tier (logical, not necessarily physical) layer. So, for those web developers out there who want the ease of use that comes with declarative data binding, I recommend they use the ObjectDataSource control and forego the SqlDataSource control altogether.
|
|
|
Message #147946
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Return to the VB 3 thru 6 paradigm of data programming
This control seems to harken back to the old DataSource control in older versions of Visual Basic. The mechanics sound very similar:
1) Drop non-visual datasource control on form/page.
2) Set properties to connect to DB.
3) Drop data display/manipulation controls onto screen.
4) Associate control(s) from step three with datasource from step one.
5) Away you go.
The problem with this is that it's only really practical for table-based interactions, but when working with multiple tables (or even multiple backends) it breaks down quickly. I wonder if a dataset is valid as the datasource for this control in the ASP .NET 2.0 framework to mitigate these problems?
I agree with what Paul implies - it seems to be a way to mock up something quick and dirty for the sake of prototyping than a way to build any kind of web interface that works with data in a non-trivial fashion. Please keep in mind, I'm not trying to "go all J2EE" on the concept and bash it for its apparent simplicity. I just worry that the widespread use of this type of control (if it is single table-constrained as is the CommandBuilder class) would lead to poor data design decisions on the backend in order to extend its usability (i.e., tables become more denormalized in a transaction-based system to accomodate the limitation).
Mike
|
|
|
Message #147971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Debates:Learn to love the SqlDataSource Control
Microsoft should put disclaimers, intended usage, audience or something at the top of their articles to qualify when to use or not to use this feature. At least we would gain some confidence that they are at least trying to give some sort of balanced guidance.
I personally this a control like this should have never been produced. This also speaks to a grip I have had with MS for a while: "The tools (VS) and frameworks (.NET) should guide developers to the best end", not by trial and error and especially not shallow "How To" tool or framework feature articles.
When we find these articles we should do everything possible to get the author or MSDN to change it.
I like these debate articles, keep them comin! We may be able to use this as a tool to keep MS honest.
|
|
|
Message #147972
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Debates:Learn to love the SqlDataSource Control
typo(I personally this -> I personally think), excuse my typing!
|
|
|
Message #147973
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tool Disclaimers
Marlon,
This is a good point. Part of Microsoft's strategy with .NET (and DNA before it) for developers has been heavy focus on a) features and b) ease of use. They really do provide a platform that can do powerful, non-trivial things, but they also include numerous tools, frameworks, and paradigms for the occupational programmer - that individual who only wants to tap into a fraction of that power for something simple and straightforward.
Nothing wrong with this, but some caveats/guidance like you suggest would really help to stem the occurrences where the two overlap and widgets, techniques, controls intended for ease of use start getting over-extended into the power end of the platform.
Mike
|
|
|
Message #148010
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not a sound architecture...
I think the control is very good for aa demo.
but
really bad for a production application.
IMHO, here
"VS.NET is not pushing the the average joe to the
pit of success" as Microsoft would like to say it.
Ricky
|
|
|
Message #148019
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
For students/newbie
Maybe for beginners in programming or students...not suited for enterprise or production but its cool though.
|
|
|
Message #148130
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
doesn't need to be black and white
I'm currently working on a project w/ 2.0 that uses a custom ORM for the heavy lifting data access. The ORM works well, and certainly complies with the classic N-tier architecture. It's responsible for any INSERT/UPDATE activities, and much of the SELECTS that occur on the database.
I personally advocate using an ORM in some form for projects of any consequence.
However, on this current project, I'm finding the SqlDataSource control a great productivity booster w/o really breaking the n-tier model much. The way I'm using it is just for SELECTS in instances where quick-and-dirty info is needed. The current project has a bunch of different 'queues' for users. These are one-off 'buckets' based on a particular user and the kind of information they want. Like a bucket for all my incomplete widgets, one for all of my widgets whose deadline complete date is near, etc. From these buckets, I would select a widget to work on, which then takes me to a page that then access the data layer through the ORM.
Using the SqlDataSource and a DetailsView, it was very easy to build these buckets. In this instance, while an absolute wall between the presentation and data layer is indeed breeched, the practical results are (1) much faster to produce (2) a very, nearly academic, merger between the data/pres layer. Again, I'm only doing SELECTS in instances where the underlying SQL would never be used elsewhere in the project. It's the simple, non-invasive parts of the app.
Another thing I should add is that I'm using the SqlDataSource programatically--I define it on the page, then set the connectionString and the SelectCommand in code. This allows me to have a static object with all my Sql in one place, and use it to set the SqlCommand for the particular SqlDataSource.
I agree that M$ should be careful how they market the control, but that's somewhat true of how they market the entire .NET monster. I think that often what we see is a clash of cultures w/n M$ -- the marketing folks ('it's so easy and you can do it w/o writing a line of code!') vs. the technical folks whom we all know would be more of the draconian nature as far as n-tier development is concerned, with the marketeers usually winning out.
Honestly, I don't know about most of you, but I generally avoid the declarative ASP controls and do a large portion of my work progammatically, anyhow. The SqlDataSource is another example of it. I'm a huge fan of <asp:placeholder> and custom controls. ;-)
|
|
|
Message #148133
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
doesn't need to be black and white
Hi Kevin,
Since you're actually using the control - are the SQL commands that it's based on limited to a single table, or can they work on multi-table JOINs as well. This was a limitation on the commands generated by the CommandBuilder class as I recall, and the concern I had in previous posts was that this was a limitation with the SqlDataSource as well.
At any rate, sounds like you're getting good sound use out of it, so all is well.
Mike
|
|
|
Message #148137
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Blogged about that a few months ago
FYI:
http://weblogs.asp.net/bleroy/archive/2004/07/12/180921.aspx
and also
http://weblogs.asp.net/bleroy/articles/157601.aspx
To summarize really quickly, consider the aspx as the declarative part of your page, and data source controls as the components that enable easy declarative communication between your controls and the underlying layers. So DataSource != data layer.
So yes, the SqlDataSource is kind of dirty/prototype-oriented, but it has the great advantage of being instantly replaceable with ObjectDataSource, or even better, your own specialized custom data-source, which is a scenario I think not enough people have considered yet.
In other words, data sources abstract the nature of the data to the controls that use them.
And I LOVE the parameter infrastructure that all data sources have.
|
|
|
Message #148153
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SqlDataSource is NOT an ORM
The SqlDataSource control can use any Select query you define, including joins, unions, etc. You specify the select as a parameterized query where the values for the parameters can come from other controls on the page, querystring, params, or several other sources.
You can't however update multiple tables with a single query (at least no way I can think off the top of my head). So you can't use the SqlDataSource control to do that using queries.
You can however do this using stored procedures. Instead of using a parameterized query, the SqlDataSource control also allows you to specify a stored procedure to call. The designer will even prebuild the Parameters list for you.
The SqlDataSource control is basically a generator for ADO.NET code. You specify the queries and parameters using HTML and it uses that to build the ADO.NET Dataset, SqlCommand, and DataAdapter objects it needs to actually perform the operation.
|
|
|
Message #148204
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Aha
Paul,
Thanks for the clarification - once I actually got into the .NET 2.0 Beta documentation (on one of numerous other machines :-) for the SqlDataSource I started to see some of what you were saying for myself.
This being the case, I'm far less against the idea of the control's use. I'm personally not much of a control guy for data access and manipulation, but for others that are and can make the right decisions it sounds like a nice, expedient way to get some things done.
Actually, one side benefit of these types of controls that can often be ignored now that I think about it: if you're unused to the environment they CAN be valuable in getting one started in how to write the proper code. Reviewing what's generated can often be a great jumping on point for obtaining "code examples" that actually pertain to one's problem at hand (vs. some generic book example). I'm sure this isn't what the designers had in mind, but any benefit is a good one in my mind.
Thanks for the clarification.
Mike
|
|
|
Message #148236
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Aha... maybe
I would agree with your statement about how useful a control like this is to lowering the learning curve to get started with ASP.NET but I may have misused the term generate. The SqlDataSource controls instantiate the ADO.NET objects to perform the data access but they don't actually generate anything that lives beyond runtime so there's nothing to learn from, except looking at the stack trace when you receive a SQLException.
|
|
|
Message #162372
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MomAndPopDataSource
This is a nice high level discussion. Can someone help explain in more practical terms what is the db performance issue of this declarative 2-tier page, specifically re connections.
The way I understand it is the SqlDataSource lives on the page it dies with every response and a new connection used for next request. Now that may be mitigated by pooling the connections but...
It does use the traditional connection, command, data adapter, dataset objects in its inner workings but not pesrsisted beyond the page so doesn't this almost obliterate concept of ado.net to handle the disconnected model? So maybe not exactly hoggin the db but too many mini-hogs.
As far as UI goes no matter how Nikhil Kotari cuts and slices it in his post there is absolutely no excuse for any non UI code disguised as markup in the design which is strictly for presentation. We don't have separate web people but I bet a lot of dev teams would have to fix broken pages mucked up by web designers. This is a horrible throwback only best described as the "neauvo spaghetti".
As far as marketting whidbey is targetting mom and pop sites. By definition, mom and pop sites do not need any disclaimers they will never scale to know the difference. also by definition Maseratti owners also know not to use Tercel gear boxes so it is a mute point both ways.
You don't see Toyota Tercel make disclaimers to buyers: "This is not a Maseratti, so don't try using it like one".
The problem is the M$ "Tercel" marketteers keep making claims they are Maserattis... All they need to do is call the control MomAndPopDataSource. It does have a place.
my $0.02
|
|
|
Message #162388
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AHA somewhat
I think what Paul is referring to is declarative code generated by for example dragging a table from the Server Explorer which generates a compllete gridview, fully configured datasource and all that WORKS.
So it is more pertient to your needs than some abstract orders/invoices helloworld db example in a book or web snippet.
Carl
|
|
|
Message #192373
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clearer Namespaces
Perhaps if this control was just placed in a more specific NameSpace:
Imports Microsoft.Corporate.CoolDemos.Controls
|
|
|
Message #194392
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MomAndPopDataSource
You don't see Toyota Tercel make disclaimers to buyers: "This is not a Maseratti, so don't try using it like one".The problem is the M$ "Tercel" marketteers keep making claims they are Maserattis...
In fact they are... Quoted from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/asp2objectdatasource.asp
"However, there is one problem with the SqlDataSource control. If you use the SqlDataSource control, then you are doing something bad. The SqlDataSource control is bad since the control forces you to jumble together your user interface layer with your business logic layer. Mixing layers, as any application architect will tell you, is just shameful.
When building a proper multi-tier Web application, you should have distinct user interface, business logic, and data access layers. Referring to SQL statements or stored procedures in the user interface layer, as the SqlDataSource control forces you to do, is just plain wrong."
|
|
|
| |
|
| New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
|
|
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|
