Category - Projects

Data Access Layer

Going into this with the plans I had for the database, I knew one of the other things I would need to tackle would be some sort of Data Access Layer.

I could have used a "plug and play" system to create it. Like LINQ or Entity Framework, but what I wanted was something to "simplify" the data. So that you could push in a form ID and get the contents info without a ton of alias'.

So you could end up with Content.Title

Even though Title was actually the value of the field's name and the data you put in there was the forms data entry for that field for the form.

This resulted in building my own API. I've initially built it with a lot of instance methods, so you have to instantiate the API first. I'm pretty sure that I'll be rebuilding that in an upcoming release to be a static method.

Building this Data Access Layer enables me to use an Object Data Source to use data in ListView, DetailsView etc, or to create my own controls (which I did and will talk about in the next post Cool)

In the end the data access layer turned pretty complex on the code side, but super slick for the end user.

I created classes for:

  • Blogs
    • BlogInfo
    • PostInfo
    • CommentInfo
    • BlogPostTemplate (this is used for BlogInfo, as it has a List<BlogPostTemplate> that stores a list of templates that posts for a blog can select to use. Enabling you to allow different posts to use different templates, or layouts.
  • BlogAPI
    • GetBlog/GetPost (overloaded to accept the ID or the url for use with the routing system)
    • Get, Insert, Update, Delete and a GetList (the GetList method was one of the main reasons for writing this custom Data Access Layer)
  • Contents
    • ContentData (not super happy with this naming convention, will likely change this to ContentInfo before the final build)
    • ContentGroupData (stores some basic info on the group of content's information)
    • MetaInfo (this turned out to be a small class added later as it helped a lot with a few of the composite controls)
  • ContentAPI
    • GetBlog/GetPost (overloaded to accept the ID or the url for use with the routing system)
    • Get, Insert, Update, Delete and a GetList (the GetList method was one of the main reasons for writing this custom Data Access Layer)
    • GetBlogMeta/GetPostMeta (still up in the air on if I'll move this over to the BlogAPI before final build)
  • Fields
    • FieldInfo (stores data about an actual input field of a form)
    • FieldRowInfo (stores data about an individual row of a form, which can contain multiple inputs)
    • FieldTypeInfo (this is used by the FieldInfo to determine if this is a dropdown list or textbox, etc)
    • ValidationInfo (stores info on the basic validatiors - might end up creating aValidationTypeInfo or dumping the FieldTypeInfo depending on the benefits of either as this code flushes out)
  • FieldAPI
    • CreateControls (probably the most important method and one of the biggest reasons for using a custom DAL, this method also holds one of the only "hard coded" switches in the system to determine based on FieldTypeID if it should create a textbox, dropdownlist, checkbox etc)
    • CreateLabels, GetValidators, GetFieldRows, GetFieldTypes, GetFields (I haven't yet made the insert, updates etc as I have not yet built out the admin interface controls, but those will be coming up as well)
  • Forms
    • FormData (important clarification, formdata, is the information that is entered into the inputs)
    • FormFields (while this one is the inputs themselves)
    • SuperNinjaFormInsertEventArgs (starting to play around with creating custom event args for the controls... more to come! Wink )
  • FormAPI
    • FillForm, FillGroup, FillLabel, FillControl, GetData (all pretty self explanatory, mostly used by the composite controls to come and the object datasource to pull from through the contentapi, the fillcontrol and label get to play with some polymorphism by passing a control around to manipulate)
    • Insert/UpdateFormDataField (these are the last two methods of the three total that use a hardcoded switch to determine textbox vs dropdownlist, text value vs string vs selection list)
  • Templates
    • TemplateInfo
    • TemplateVariables (this is to store the options for the routing engine, like default values, is catch all, etc)
  • TemplateAPI
    • GetPostTemplates, GetTemplate (used by the routing program as well as the blogapi uses the get post templates to create the dropdownlist)


Obviously the API is still flushing out as I build more composite controls or build the site out further and find something I didn't forsee in the beginning, like having the custom event args to be able to cancel an insert.

I'm also looking forward to optimizing this with some inheritance as I determine what properties and methods objects share.

You must be logged in to comment.