Is it really professional to use the data source controls in ASP.NET?

Question

Hi,

I'm in the process of learning ASP.NET. I bought some books on the subject. All of them suggest that using the data source controls, like ObjectDataSource/SqlDataSource etc. are the way to go. Now, I'm definitely not an expert on the subject, far from it actually. but I have a strong feeling that these are toy tools. I have a hard time believing that these classes would be used in a real world, enterprise grade application. Am I right? Or do these classes actually do have a place in large scale web applications?

Thanks, Avi

Answer 1

These controls have gained a bad reputation due to inexpert developers using them without understanding them, and professional developers looking down on them as a result. The best advice I can give you, is that a professional will use whatever tool is the most appropriate, and which gets the job done without getting in the way. If these tools do the job for you, then you should use them and don't let people put you down for it.

Answer 2

They are great for populating a bound control if the query is simple, like a dropdown list of categories. They are rather painful for doing custom searches or the like. Evaluate your approach on a case by case basis.

Answer 3

Personally I prefer to wire stuff up myself. It is pretty simple to run stored procs to retrieve data and assign it to data entry controls without using data binding. It is also easy to grab the modified data and add, update, or delete as needed. The data source classes add what seems to me to be an unnecessary extra layer. If they were significantly simpler than the way I do it I might give them a shot, but they seem pretty complex to me. And, even though I don't have any benchmark data to prove this, it seems they must be less efficient.

Answer 4

Couldn't agree more - mixing in database connection stuff with HTML, potentially business logic, etc, etc is a very bad idea in the modern world of unit testing, DDD, TDD, etc.

There will be situations where they're appropriate (maybe the simplest of reporting tasks that need to be done in a hurry, mockups) but in general avoid them.

Answer 5

I think one could argue that using ObjectDataSource is reasonable, presuming it is actually talking to a real middle-tier of objects. Especially if the developers extend ODS to play with their middle-tier.

The others will get your fingers broken (2nd offense) in my shop.

Answer 6

The first thing you need to realize about ASP.NET is that, everything related to server controls, and the webforms paradigm in general, will never perform as good as Response.Write(). The whole idea of webforms is to get you from point A to point B as quickly as possible. So, before you choose webforms you should ask yourself, is this the best framework for my app ? For high traffic websites, and/or if you strongly care about design patterns, I would choose MVC without a doubt.

Now, if you do choose webforms, then I highly recommend that you use data source controls. It will make your life easier. I don't know how you define enterprise grade applications, but datasource controls can achieve great things. I recommend you look into LinqDataSource, EntityDataSource, the new DomainDataSource, the new QueryExtender and how these work with any IQueryable source.

Answer 7

Well, I see that the opinions are mixed. I guess that I will give it a try, just so I get a first impression, if nothing else. I have a feeling that I will abandon it in the end. Comming from a server side development background, I just find it very hard to put any logic in the UI layer, even it is just 'declarative'.

Thanks guys :)

Answer 8

I agree with Wyatt and figured I should add a little bit more information. The problem with all the data source objects (other than ObjectDataSource) is that you are unable to split your application up into logical tiers (i.e. UI, business logic, data access). You are putting all of your data access code in your UI, and that is very bad from an architectural view of your project.