Basic CRUD Development With ORM/Telerik/WCF – Part 2 – ORM

For our project, we can use the Lite version of LLBLGen Pro, which is limited to eight entities per project.

Here is a screenshot of the LLBLGen Pro project I used:

When working with the LLBLGenPro ORM, I found a need to generate not only the regular entities, but also objects called “Typed Views” to serve as DTOs (Data Transfer Objects).  Most ORM entities have extra metadata to manage state, such as “IsDeleted” properties.  This makes working with them powerful, but adds overhead to the payload in a Service Orientated Architecture (SOA).  I wanted to be able to use DTOs, or POCOs (Plain-Old-C#-Objects) as they are also known, between the service tier and the presentation layer.  This ORM allows me to generate these DTOs, saving me a lot of time.

The class diagrams below show the difference between a entity and a typed view:

Eventually, I want to serialize the typed views into lightweight JSON objects.  Serializing entities creates a complex JSON structure that does not work well for a REST-full application, as we shall see.

Basic CRUD Development With ORM/Telerik/WCF – Part 1 – Database

The LPA (Landing Page Admin) database is pretty basic, with eight tables, but I will only use four for now.

Here is the database diagram:

Templates – Each Landing Page has a template, which contains metadata about the page.

GlobalTokens – Tokens stored as named-value pairs that apply to all templates.

TemplateTokens – Each template will inherit a set of global tokens.

Patterns – Patterns are the layouts that define the template (2-column, 3-column, etc.)

You can download the SQL script below to create these objects, but it may be easier to create a database called “LPA” and execute the part of the script that creates the objects.  There are also some other objects used by logging that are in the script.

 SQL Script on Dropbox

Create Database Script as Word Doc

Basic CRUD Development With ORM/Telerik/WCF – Intro

I recently finished up an engagement at a client where I had to build a fairly basic but robust application to manage landing pages.  Landing pages are are exactly what they sound like – pages that a web users “lands” on if they are searching for a site.

In this project, the company had over 50 landing pages, and all of them were distinct sets of static HTML with their own set of CSS/JS and images.  They were hosted on the web, and it was a nightmare to make to changes to all sets of landing pages because a developer would have to pull down the content, edit it, and the upload it back to the website.

One of the problems the company was having was that the pages weren’t entirely static.  Many had dynamic content that had to be “injected” when the pages were rendered.  Some of this data was content like interest rates, which change frequently.  In addition, this company had many different lines of business, and each had their own phone numbers, some of which changed frequently.

I will demonstrate in the next series of posts how I built a distributed ASP.NET MVC application to manage these landing pages.  The goal was to be able to tokenize the content that changed frequently, and use the power of MVC to render the landing pages with a mix of static and dynamic content.

None of this was rocket science, but there were some constraints.  Of course, it had to be a distributed SOA application, for scalability reasons, and besides, tightly coupled monolithic applications are just bad.  Also, the company had a very onerous build and release process, and standing up intranet sites was essentially impossible.  There was just too much push back from DevOps to let us setup up a project that required much ops support, even it was an internal app.  Also, it couldn’t require much environmental-specific configuration settings.

It just had to work, without ops getting involved.

Normally, for a project like this, I would create a website, setup a WCF service tier, and expect to host both on IIS.  But this was not your typical company 🙂

I also wasn’t going to get a dedicated DBA to write my stored procedures, and in any event, I didn’t want to use any.  This was a place where they still wrote tons of procs for basic CRUD applications, and expected the devs to write tedious ADO.NET code.

Really?  Hey – the 90’s called, they want their application development process back 🙂

So I had to, and wanted to, use an ORM.

And it wasn’t going to be Entity Framework.  EF is a nice, free ORM, but you get what you paid for.  I prefer a world class ORM, like LLBLGen Pro.

I also didn’t want to deal with a ton of WCF ServiceModel configurations – ops would not help when we had to change endpoints as we moved from DEV to QA to PROD.  So I explored some WCF self-hosting options that I scrounged up on the internet.  BTW, ServiceStack would have been great for a project like this, but an elegant, basically config-less,  endpoint-ignorant, and dependency-free service architecture would have been a bold and revolutionary concept at this company.

Finally, I wasn’t about to re-invent the UI wheel and handcraft my own client-side grids and write tedious javascript to input and render data.  I would use a 3-rd party component suite that was responsive and robust.  That would be Telerik Kendo UI.

I know, I hear you purists out there…

“WHAT IS THIS SORCERY YOU SPEAK OF?  BLASPHEMY!  THOU SHALL WRITE EVERY PIECE OF CODE IN AN APPLICATION!  NO EXTERNAL DEPENDENCIES!  NO ORMS!  NO 3-RD PARTY COMPONENTS!  NOT EVEN F-ING JQUERY!”

Yeah, right.  This is an internal CRUD app, not FACEBOOK or even GOOGLE.  I don’t need to write yet another JSON parser, logging component, tabular grid, or my own responsive CSS framework, service bus, or inversion of control container.  I make a living writing robust business applications quickly and efficiently, not indulging my hacker ethos.

Any way, I’ll go through the process in a few posts and upload the source to  GutHub.

Here’s a screenshot (I know, I told you it was basic):