locked
Using Data Sources vs. Using Data Access Layer to populate Presentation controls. RRS feed

  • Question

  • User-1253409855 posted

    Background:

    We are using a tierd design with a Data Access Layer and classes for everything we need. This serves as an advantage because we do not have to write querys over and we can separate the Presentation layer from the Data Access Layer and Business Rules.

    I have always in the past populated GridViews, DataLists, repeaters,etc with SqlDataSources. This is what I have become accustomed to and I feel like it is simple. For querys such as Select * from Members, I feel like using a DataSource is simpler than having to go in the code and calling methods to populate and DataBind these presentation controls.

    I am working with a gentleman who has introduced me to the world of Data Access Layers and we are breaking everything down into simeple, but effective queries to populate controls and do what we need to accomplish with this application. He is not very approving of using any type of DataSource. We are disagreeing on the time and place to use these class methods to call the database.

    So my question is, which is more widely used in the programming world? Do most people use DataSources to populate presentation controls regardless of the Data Access Layer they are working with? Which type of queries are best suited for a DAL - simple, populating queries or complicated joins and upserts?

    Wednesday, March 17, 2010 6:15 PM

Answers

  • User-1179452826 posted

    IMO, datasources are one of the greatest evils of webforms, and they're also very much necessary to make webforms work. Here's the thing - if you have datasources with direct db queries, you have to have them on each and every page, there's no way on earth to unit test them, you won't see errors until runtime (i.e. before integration testing) and you'll have to write  the same query on each and every page. If you have a complex query that interacts wth codebehind in any way, that too has to be replicated on every page that uses the functionality. When, rather than if, business requirements change, every instance of that string based query will need changing. Miss one and you're cursing more than an R rated film.

    That doesn't mean that you can't use a DRY appoach at all in webforms. There's a certain datasource that exists to serve the reusable data object approach - it's called the object datasource. It basically accepts the type of the business object doing the querying and the method to be called on the business object, also parameters to be passed to it. But it does NOT hold any queries directly. Gridviews, listviews, detailsviews and formviews can bind to them.

    Here's the approach I take - I build my data access and business layers as repositories and services respectively. Then I choose Asp.net MVC. If I'm forced to use webforms for whatever reason, I don't change the data acceses or business layers at all. I create a wrapper Object DataSource that calls out to the business layer classes. And I bind to the Object DataSource in my aspx markup. This does add an extra layer of abstraction, but at least my data and business layers are reusable outside of a webforms context and remain testable.

    That said, if you're making something quick and dirty, you could easily use SqlDataSources and put your queries in the markup directly. Just remember that if it starts to get the slightest bit bigger and more complex, you'll be wishing you didn't go that route.

     

    Hope that helps.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, March 17, 2010 11:15 PM

All replies

  • User-1179452826 posted

    IMO, datasources are one of the greatest evils of webforms, and they're also very much necessary to make webforms work. Here's the thing - if you have datasources with direct db queries, you have to have them on each and every page, there's no way on earth to unit test them, you won't see errors until runtime (i.e. before integration testing) and you'll have to write  the same query on each and every page. If you have a complex query that interacts wth codebehind in any way, that too has to be replicated on every page that uses the functionality. When, rather than if, business requirements change, every instance of that string based query will need changing. Miss one and you're cursing more than an R rated film.

    That doesn't mean that you can't use a DRY appoach at all in webforms. There's a certain datasource that exists to serve the reusable data object approach - it's called the object datasource. It basically accepts the type of the business object doing the querying and the method to be called on the business object, also parameters to be passed to it. But it does NOT hold any queries directly. Gridviews, listviews, detailsviews and formviews can bind to them.

    Here's the approach I take - I build my data access and business layers as repositories and services respectively. Then I choose Asp.net MVC. If I'm forced to use webforms for whatever reason, I don't change the data acceses or business layers at all. I create a wrapper Object DataSource that calls out to the business layer classes. And I bind to the Object DataSource in my aspx markup. This does add an extra layer of abstraction, but at least my data and business layers are reusable outside of a webforms context and remain testable.

    That said, if you're making something quick and dirty, you could easily use SqlDataSources and put your queries in the markup directly. Just remember that if it starts to get the slightest bit bigger and more complex, you'll be wishing you didn't go that route.

     

    Hope that helps.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, March 17, 2010 11:15 PM
  • User-1253409855 posted

    Good answer. I do not have experience with MVC. I need to look into that. Also, what did you mean by a wrapper ObjectDataSource?


    Thursday, March 18, 2010 10:12 AM
  • User187056398 posted

    If the data queries are complex and may change in the future, encapsulating them in a separate layer is good.  You can beat them up, test them, validate them and perfect them away from the main program.  The layer can even be used by more than one program.

    However, making a separate data layer simply for the sake of making a separate data layer is not efficient.

     

    Thursday, March 18, 2010 10:15 AM
  • User-1253409855 posted

    I agree. This being my first real application that is layered, I am learning the basics and when to decide to use that type

    Thursday, March 18, 2010 11:06 AM
  • User-952121411 posted

    He is not very approving of using any type of DataSource. We are disagreeing on the time and place to use these class methods to call the database.
     

    My thoughts on the SQLDataSource control and all of the UI 'Wizzardy' type controls (Object Data Source excluded) were targeted more for a 'get-up-and-running' crowd not too overly concerned with making large scale enterprise application with scalability, performance, and reuse in mind.  I think they are quite analogous to the (2) distinct ASP.NET project types in VS.NET: The Website Project and the Web Application Project.  The Website project type has to me also fallen in the 'get-up-and-running' style development, by hiding many of the lower level settings, details, and abilities that a Web Application project provides.  I think Microsoft wanted to target a larger audience, and created things like a Website Project template with the ability to drop a few SQLDataSource controls on a page, so either an entry level programmer or someone without a lot of time could code, publish, and be done!  To some this is quite an attractive feature.  However, this type of development does not suit the majority of the target audience I would gather in this forum.

    I agree that a better approach is to assign responsibly of code to logical layers, that promote OOP design and capitalizing on code reuse.  Paring your application into an n-layer logical design using a DataLayer is typically a much better route to follow.  You just need to asses what type of project you are building, and what the needs are; you may need to publish a single page quickly for a small internal audience and don't have a lot of time for design and building out a bunch of layers.  In this case, the Website and tools like a SQLDataSource may be appropriate.

    Hope this helps! Smile

    Thursday, March 18, 2010 2:56 PM
  • User187056398 posted

    However, this type of development does not suit the majority of the target audience I would gather in this forum.
     

    I don't think you can draw that conclusion.

    If a DataSource works for the majority of applications, the developers will not need to access this forum because they have a working web site and have satisfied their business requirements.  Satisfying the requirements with the least amount of effort is the hallmark of excellent engineering.

    If they are over engineering simple tasks (and this happens WAY too often) they will spend more time on this site trying to dig themselves out of the hole they put themselves in.

    The right tool for the right job.

    Thursday, March 18, 2010 3:06 PM
  • User-952121411 posted

    I don't think you can draw that conclusion.
     

    You might be right; I certainly did not take a poll.  I should have been more specefic and stated the 'Architecture' forum and not imply the ASP.NET forums as an enirety.  My conclusion was based on the fact that I do not believe based on the questions I see and read and the design patterns and practices being used, that many of the developers here in this (Architecture) forum are plopping down SQLDataSource controls with "SELECT ID, Product, Descritpion FROM ORDERS" right in the page's source, when a slew of questions are regarding EF, MVC, n-layer, SOA, GOF design patterns, etc.  The 2 don't in my experience go together that well, but I certainly will change my opinion on the SQLDataSource if others using the aforementioned technologies speak up in its usage.  I though my assesment of it being more of a 'get-up-and-running' tool was somewhat accurate.

    The right tool for the right job.

    Well put, and I thought I kinda stated that too, but maybe I didn't convey it well. Undecided

    Me: "You just need to asses what type of project you are building, and what the needs are; you may need to publish a single page quickly for a small internal audience and don't have a lot of time for design and building out a bunch of layers.  In this case, the Website and tools like a SQLDataSource may be appropriate."

    Thursday, March 18, 2010 3:22 PM
  • User-1179452826 posted

    "The right tool for the right job" -

    That's one of the reasons I like MVC. With MVC, if you follow even "good" practices, then if you find out later that your requirements have got more complicated, you can very easily change the implementation for data access / business logic without touching the hard-to-test UI layer. With webforms, if you select a sqldatasource and create a bunch of pages, any change in the requirements and you're stumped. As such, I create an ObjectDataSource that simply calls out to the testable and flexible repository / business service. Anything that acts as a shield between change and change in the UI layer is fine by me. 10 minutes today might just save a few hours down the line.

    Friday, March 19, 2010 12:15 AM
  • User-525215917 posted

    You can make also ASP.NET Forms testable if you use MVP pattern. But I too suggest you to take ASP.NET MVC for web applications. :)

    Friday, March 19, 2010 3:57 AM