none
3 tier application - some advice RRS feed

  • Question

  • I have a simple class structure, 3 classes inheriting from a base class.

    BaseWidget //my base class
    SimpleWidget : BaseWidget //inherits from basewidget
    ComplexWidget : BaseWidget //inherits from basewidget
    ExtraComplexWidget : BaseWidget //inherits from basewidget


    I have a very simple web application that uses a

    • Data layer (CS file in App_Code)
    • Business layer (CS file in App_Code)
    • Presentation Layer (ASPX page and code-behind)

    The datalayer connects to a SQL server database and has just one method:
    public static List<BaseWidget> GetAllWidgets() // returns a list of Widgets

    The business layer doesn't really do anything in this application, its used more when the user is inserting a widget as it validates the entries etc..

    The business layer method (Widgets) simply creates an instance of the datalayer and calls the above method.

    I then use an objectdatasource control with its select method hooked up to the business layer method(Widgets) and a repeater bound to the objectdatasource.

    Usual sort of stuff.

    Each widget in the database can be either a simplewidget, complexwidget or an extracomplexwidget.
    In my repeater I show the name of the widget and a link to a page which shows more detail about that widget - how can I create a details.aspx page that will show all of the information for each widget, without having to create a seperate aspx page for each type of widget.

    I was thinking about using 3 user controls, simple.ascx, complex.ascx and extracomplex.ascx and then depending on the type of widget, adding one of these to the page programtically?

    Thing is, I want to keep this as textbook as possible and I'm striving to keep it 3-tiered as much as realistically possible. Am I going in the right direction?



    Monday, March 9, 2009 5:13 PM

Answers

  • I think you are heading in the right direction.  You could create 3 views in the database.  Simple widget details, complex widget details and extracomplexwidget details.  You can then UNION your views and return all that data in a single query from your Data Layer.

    Or you could do all of that in your Data Layer or Business layer and get the same result.  Some will argue that moving business logic down to the database level is not good stating that the database is for table data lookup only.  And while creating 3 or 4 views is not traditional "business logic" it's for a specific business purpose.

    I like putting logic at the database level where it makes sense without overkill.  In this case I think it makes sense to put this into the database.

    Hope this helps, somewhat!

     


    Ryan
    Monday, March 9, 2009 6:56 PM

All replies

  • I think you are heading in the right direction.  You could create 3 views in the database.  Simple widget details, complex widget details and extracomplexwidget details.  You can then UNION your views and return all that data in a single query from your Data Layer.

    Or you could do all of that in your Data Layer or Business layer and get the same result.  Some will argue that moving business logic down to the database level is not good stating that the database is for table data lookup only.  And while creating 3 or 4 views is not traditional "business logic" it's for a specific business purpose.

    I like putting logic at the database level where it makes sense without overkill.  In this case I think it makes sense to put this into the database.

    Hope this helps, somewhat!

     


    Ryan
    Monday, March 9, 2009 6:56 PM
  • Cheers for your reply.

    The database table is quite simple and I'm thinking of wrapping up the extra details for the complex and extracomplex widget into a fragment of XML in the database. Then I only need one table, and to be honest, there is no real reason to add extra tables, I won't need to search on it or do anything clever with the extra details..

    e.g table structure
    widget-id
    widget-name
    widget-notes
    widget-type
    widget-xml-details <--- all the info about the widget is in here
    widget-published

    therefore... when I need to pull back all of the widgets, I can just 'select * from widgets'
    Some will be simple, some will be complex and some will be extracomplex. 

    So what I'll get back is a List<Widgets> from my data layer - each widget could be different.. I then thought about using the 'widget-type' field to identify it(see above), this could contain 'simple', 'complex' or 'extracomplex', or 1,2,3 I guess.. and therefore process the xml in the 'xml-details' field accordingly based on the value of widget-type.

    Ok.. so, I've got the widget objects in a list in my business layer... and I bind that to my objectdatasource..

    Mmmm, so where am I going with this?  :)

    Is it still fully textbook n-tiered app if I add code to the aspx codebehind page that processes what usercontrol to add to the page..
    I'm adding code into the presentation layer aren't I? Or is that ok, as its used for formating and organising the layout?

    I think I've lost my way a little, so I'll stop rambling.. :)



     
    Monday, March 9, 2009 7:38 PM
  • Is it still fully textbook n-tiered app if I add code to the aspx codebehind page that processes what usercontrol to add to the page..
    I'm adding code into the presentation layer aren't I? Or is that ok, as its used for formating and organising the layout?

    I think I've lost my way a little, so I'll stop rambling.. :)

    Your right on.  Your logic is to figure out what to 'Present' thus the presentation layer is the BEST place for that.

    Lets say you were going to email the list of wigets to your co-worker.  You presentation layer would need an 'Send EMAIL' button which by clicking would ask for an email address.  The logic for sending the email would go into your business layer.

    The business layer might also be where you keep your STATE information.  Which widgets did the user look at, stuff like that?  So you can give feedback during the user session.  Of course this info would go away when the user closes the browser or your desktop application.  If you want to keep some of this state information for a longer period of time, you'd send the information to the database, or some other type of storage (cookies in the browser, or local file for a desktop client, etc) making use of the DATA layer.

    That is how shopping carts are typically used.  Some website shopping carts are only kept alive during your session.  Most of them however utilize cookies.  Of course cookies only works if you use the same machine to view your shopping cart.  Now some sites also have Wish Lists, in that case most of that data is kept in the database so it can be brought back to the user no matter where they are.

    Look, I'm rambling too!!

    Ryan
    Monday, March 9, 2009 8:01 PM
  • Cheers Ryan, very helpful. :)

    So, even when I do some XSL transformations in my example, thats ok to do in the code-behind page of the ASPX, because its presentation.

    I'll rattle that up now...


    Monday, March 9, 2009 8:21 PM