locked
Presentation RRS feed

  • Question

  • User-82967589 posted

    I'm just wondering how does everyone design for various presentation needs?

    For example - say you have BLL classes for entities like Departments and Employees.

     

    On a Department summary page, perhaps you wanna show all the Employees in the department in a GridView, but you want some data that is not an Employee attribute, but is related to Employee, such as the employees last performance review score... or the employees sales this month... whatever.

    I typically work with ObjectDataSource in my GridViews.  This means I typically need to write classes for virtually every situation in which I want to display different combination of attributes/fields from different tables.

    So in this example, I'd end up writing a EmployeeSummary class that has the employee name and what not, plus the review score, sales etc and whatever other fields I want in the summary.  Then I have to write DAL and a stored procedure to get the data.

    Is this what others are doing?  Is there something better I should be doing?

     

    Thanks!

    Tuesday, December 15, 2009 3:00 PM

Answers

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, December 17, 2009 12:21 AM
  • User-952121411 posted

    Well your questions are good, but it one of those scenarios where there are so many ways to conquer the situation and not any 'right' or 'wrong', but more like 'good' and 'not so good' approaches.  I guess you are looking for the 'good' or 'better' approach to your situation of needing to mix the data for certain controls.

    In my experience and preference I always like to make chunky calls to the database, rather than multiple small calls; especially for static data like Employee for example.  If most of the employee data you are working with is static for the web session and not changing, I would feel comfortable getting all of it and populating an object that can be persisted in Session and reused, rather than going back to the database for small drinks of water every time you need a little more information.  Now this doesn't always apply, but you can look at your overall design and determine which sets of data can be brought back and persisted for re-use over and over.  

    Now to meet the needs of the side data like YTD sales, work schedule, etc, you may look at class inheritance if it makes sense in certain situations and populating a more robust object up front, or possibly populating individual separate objects to also be persisted for re-use.  These could be used together with the addition of some logic to get you all of the data variation you need to populate your UI controls without going to the database 100 times, and writing 100 individual small methods to get that data.  The Object Data Source generically will want you to write individual objects and wired up methods for each ODS and operation, so it tries to mold your design a bit.  I have come to the conclusion that I like the ODS for controls like a GridView, but do not try and use it for single smaller controls (i.e. a DropDown).

    It takes a little more work to kind of 'interject' a persisted objects data when using an object data source, but it is possible.  The ODS wants to fire the .Select() method for everything, but you can dictate that wired up method parameters and such to change directions of where to get the data based on logic.  If you already have an object populated, don't go get another, or use caching which is even better.

    It sounds like you are on the right path, but you may need to modify some of your objects and how you apply them to the ODS in order to get a more efficient and streamlined design.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, January 4, 2010 4:41 PM

All replies

  • User-82967589 posted

    I guess some people might be using lazy loading.  So my Employee class above might load the sales and whatever other things when they're needed.

    Or maybe a class that inherits employee and adds sales stats etc.

     

    I'm interested to hear what others are doing.

     

    Tuesday, December 15, 2009 3:43 PM
    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, December 17, 2009 12:21 AM
  • User-82967589 posted

    Great book - I've actually looked at it before, but I'm not sure if that's exactly what I'm seeking.

     

     

    Thursday, December 17, 2009 3:50 PM
  • User-82967589 posted

    Maybe more information will help.

    Most often, I am using DAL classes to call DB stored procedures and return Business Objects.  So for an employee form, it's pretty straight forward that I need an Employee Class in my BLL with all the attributes of an employee and my DAL will have a dalEmployee that has a GetEmployee method that calls the stored procedure spGetEmployee.

    But when I start mixing things up, on summary pages and lists - I'm not sure how I should structure things.  Keeping with the example, perhaps I need to show a list of Employees and their YTD Sales and maybe the last day they worked... so fields: LastName, FirstName, SalesYTD, LastWorkDay.

    Most of the time I don't need Sales and LastWorkDay.  So it seems like waste if I always return those fields from my stored procedure.  So its not a question of lazy loading I think - I'm still querying everything all the time if I do it this way.

    For these cases, I've been creating additional stored procedures that return just what I want, along with additional BLL classes to hold the data and additional DAL classes to retrieve it.

    Was just wondering if others had better ways of doing things and I'm not finding any particularly relevant subject in the book mentioned above.  I think the kicker is the fact that I'm using stored procedures for all of my database operations.  So unless I want to constantly hit several additional tables for rarely needed information, I'm stuck with creating additional procedures.

     

    Thursday, December 17, 2009 4:08 PM
  • User-82967589 posted

    Well, I've just continued my pattern of writing an additional BL & DL classes and stored procedure.

    So for the example above -

    I now have an EmployeeSummary class (for lack of a better name) and DALEmployeeSummary class, along with a procedure to get it.

    Just seems to result in an aweful lot of small classes.

    Tuesday, December 29, 2009 11:39 AM
  • User-952121411 posted

    Well your questions are good, but it one of those scenarios where there are so many ways to conquer the situation and not any 'right' or 'wrong', but more like 'good' and 'not so good' approaches.  I guess you are looking for the 'good' or 'better' approach to your situation of needing to mix the data for certain controls.

    In my experience and preference I always like to make chunky calls to the database, rather than multiple small calls; especially for static data like Employee for example.  If most of the employee data you are working with is static for the web session and not changing, I would feel comfortable getting all of it and populating an object that can be persisted in Session and reused, rather than going back to the database for small drinks of water every time you need a little more information.  Now this doesn't always apply, but you can look at your overall design and determine which sets of data can be brought back and persisted for re-use over and over.  

    Now to meet the needs of the side data like YTD sales, work schedule, etc, you may look at class inheritance if it makes sense in certain situations and populating a more robust object up front, or possibly populating individual separate objects to also be persisted for re-use.  These could be used together with the addition of some logic to get you all of the data variation you need to populate your UI controls without going to the database 100 times, and writing 100 individual small methods to get that data.  The Object Data Source generically will want you to write individual objects and wired up methods for each ODS and operation, so it tries to mold your design a bit.  I have come to the conclusion that I like the ODS for controls like a GridView, but do not try and use it for single smaller controls (i.e. a DropDown).

    It takes a little more work to kind of 'interject' a persisted objects data when using an object data source, but it is possible.  The ODS wants to fire the .Select() method for everything, but you can dictate that wired up method parameters and such to change directions of where to get the data based on logic.  If you already have an object populated, don't go get another, or use caching which is even better.

    It sounds like you are on the right path, but you may need to modify some of your objects and how you apply them to the ODS in order to get a more efficient and streamlined design.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, January 4, 2010 4:41 PM