lazy loading dependency objects and dependency ID persistence

July 16th, 2010

I’m having an issue with the way I’m going to do this and I’ve been thinking about it for the last couple of days.

I have this entity object, say a Person object, and each person has a many-to-one mapping of say, an Employer object. Now I know a person can technically have more than one employer, making this a many-to-many relationship, but I’ll say for my purposes that each Person can have only one Employer but each Employer can have many Person objects associated with it. This is most likely the case in the real world anyway.

I’ve created some entity classes for objects such as these and I’ve come across a problem. How will I persist the Employer relationship for any given Person object. For example, Person A has a name, birthdate, and Employer ID. However, in my Person entity (my POCO), I’d like to have each Person have an Employer object rather than just an Employer ID. The difference would be like this:

personA.EmployerID vs personA.Employer.ID, personA.Employer.Name, personA.Employer.Address, etc.

I can do this, but I want lazy loading. In other words, I don’t want the Employer object to be fetched from the database until it is used by invoking personA.Employer.<value> for the first time for any given instance of the Person class.  The reason for this is the performance cost that eagerly loading all the dependent objects of any given entity might incur. It wouldn’t be so bad if the only dependency here was the Employer object, or even other laterally dependent objects within the Person class, such as personA.Pets, or personA.Girlfriend. However, what happens when I have a ladder of dependencies such that Person has an Employer, and Employer has an associated CEO object and a BoardOfDirectors object and an Address object. BoardOfDirectors then has a person object for each position and each position has a PhoneNumber object and on and on. So now when I want to load a person’s name, I will also have to reach into an Employer table, an Address table, a BoardOfDirectors table, and a PhoneNumbers table, at minimum! This is why I need lazy loading if I’m going to be doing things this way. That way when I want personA’s name, the only table I will need is the People table and I’d only need other tables when I call the related properties from my personA instance.

The other problem I have is saving a person’s Employer object when it’s changed. Really, in the People table all I’m going to be having to associate the Person to the Employer is an Employer ID. However, my POCO will have an Employer type, not an Int type EmployerID asociated with it. But when I want to save a new Employer to personA, all I will need to do is change the EmployerID value in the People table to correspond to a matching Employer row in the the Employers table. However, I don’t want to have to pull from the Employers table just to change the peopleA.Employer object only to need just the ID for the People table’s EmployerID column. This is a tough one because I know I can just add an EmployerID property as well, but then it becomes kind of unclear which to use. I could make the EmployerID a mutatable only property maybe? Then the Employer object could be accessible only; not mutatable. I don’t know. I’ll think about it.

NHibernate ambiguous error reporting… not so ambiguous??

June 26th, 2010

A few days ago I ran into this error when trying to view a website I’ve [kinda] built using NHibernate 2.2:
Could not determine type for: System.int32, for columns: NHibernate.Mapping.Column(DescriptorID)

I had a hard time trying to figure out what that error means. I didn’t think it should be so difficult, considering I’m just trying to recreate Rob Conery’s Kona code, and I should just be able to compare it to that.  I’ve looked through the code trying to understand how NHibernate works in the first place and what the error means exactly, but I couldn’t figure it out.

I ended up going to http://nhforge.org/wikis/howtonh/your-first-nhibernate-based-application.aspx and reading the beginner’s NHibernate guide, which by the way isn’t written very well (as in it is not as detailed as it should be), but does present some great information; and on that note, anyone who is novice to either ASP.net or NHibernate will have a lot of trouble getting through it. If it wasn’t for Rob’s code, I ‘d have had a much more difficult time figuring it out myself.

After finishing the NHibernate tutorial, I felt that I understood how NHibernate works a little much better, but still had no solution to my problem. What I did have, however, was a better grasp of TDD (Test Driven Design), which I started to employ on the MVC Storefront in hopes of at least pinpointing the source of the problem… and I did.

I should probably mention that Rob has a few webcasts about Kona (MVC Storefront), where he talks about TDD. He uses it a lot in creating the store as well, but it’s much easier to grasp when I actually did it myself in a different context, which is what that NHibernate tutorial allowed me to do.

The Solution To My Problem

After employing what my limited understanding of the TDD process would allow me, I narrowed down the problem to a single file. This file was [KonaDirectory]/Model/Supply/Descriptor.hbm.xml. I did think that this file might be the source of the problem early on, but after comparing Rob’s version of the file and mine over and over and over, I couldn’t understand why his worked and mine didn’t. It wasn’t until TDD confirmed to me that that was indeed the problem that I started scratching my head and looking at the two files line for line. Then finally I found a difference in the line: <id column=”DescriptorID” type=”System.int32″>. In Rob’s file, the text ‘int32′ was capitalized. The error was exactly where NHibernate said it was, I just missed it over and over as I sifted through the file trying to find a problem. The unit test, however, saved me in the end.

So, I changed int32 to Int32 and the error went away, and I got a whole new error. But who cares? I was just happy that I was finally moving along again.

jQuery, MVC, etc.

June 17th, 2010

Things I have been trying to become really good at:

  • jQuery Just another JavaScript library. Not really though, because jQuery it’s quickly becoming the de-facto JavaScript library out there. Developed by John Resig, who was able to make JavaScript really easy, jQuery brings consistency to the way things are called, accessed, and manipulated in JavaScript. I can’t say jQuery is the best JavaScript framework out there, because I haven’t used them all. I know there are some other popular ones like Prototype and Moo Tools, but I probably won’t have a reason to get accustomed to them for a bit, if ever, as long as I can get what I need done using jQuery. However, what I can say about jQuery is that it has become heavily used and talked about and those two things made it worth at least looking at. I’m glad I took the time to get used to it because now I can do things on the client that I used to think I would only be able to do using Flash.
  • Microsoft MVC, or just MVC in general Model View Controller software design pattern. This is a great pattern for website development because it cleanly and logically separates your concerns, and since the UI in web development (HTML, JavaScript, CSS, Flash, etc.) is so much different than other logical layers (server-side languages), you’ll want them separated and coupled as loosely as possible. MVC is great because it only sends and retrieves results to and from your UI layer (view) using transport-type classes (controller) and has really nothing else to do with the UI beside that. This leaves developers free to change logical processes or presentation code without one affecting the other (or doing so minimally).
  • Multilayered Architecture I like multilayered development because it’s straightforward. In this type of architecture, you have as many logical layers as you need, depending on the requirements of the software. However, I think that no matter how many layers this type of architecture ultimately will require for any given design, it’s basically going to come down to 3 major tiers (not as in physical separation, but as in major group of logic): a data access layer, business logic layer (domain layer), and a presentation/UI layer. These layers can even be physically separated on different CPUs for performance benefits, but I have never had the need to do that (yet). Like MVC, these layers separate your concerns, but a little differently. Data access logic and business logic are cleanly separated (in MVC business logic is kinda split between the M and the C) and business gets its own layer. There’s not really a controller per se, but something similar can be built within the business layer to perform the same type of function.
  • Other stuff Dependency Injection, Inversion of Control, PayPal integration, the Repository design pattern, Test Driven Design, Domain Driven Design

adding a folder back to a project

February 4th, 2010

So there’s a class project I’m working on in Visual Studio 2008 and there were a couple of files I wanted to exclude temporarily so I could test some stuff out without getting errors from the unfinished files. Well these two files were in the same folder so I just right clicked on the folder and selected ‘Exclude From Project’, which worked great. But then I tried to re-add the folder to the project, which is not really an option you’re given in Visual Studio 2008 if you just right click on the project name and choose from the ‘Add’ menu.

What I did see when I chose ‘Add’ from this menu, was the ability to add a single file back to the project, so I decided to try this and hope it would also add the folder structure that the file was contained in. However, the result was Visual Studio making a copy of the file in the root directory of the project and adding that to the project. Doh! Well this actually makes sense when you’re adding a file that is not already within a directory that is a child of the root of the project. But when adding a file that is contained under the root of the project, you just end up with two copies of the file; one that is still not included in the project but is exactly in the location you want it in, and one that is included but is at the root of the project, which is no bueno.

Adding an entire folder is different, but just as easy as adding a file. At the top of the window of the Solution Explorer, just under the words ‘Solution Explorer’, there are many different buttons to do things like view the properties of a selected item, view code structure, refresh the directory, etc. Located on this bar, right to the left of the refresh button is the ‘Show All Files’ button. If you click it you see all the ‘ghost’ folders and files in the project. From here you can just right click on any of the files of folders not already included in the project, choose ‘Include In Project’, and you can guess what happens next. Problem solved.



The ‘Show All Files’ button. If you don’t see it, you probably don’t need it.

membership and roles

January 21st, 2010

I’m working with ASP.NET’s excellent membership and roles API’s and the extensive controls available to do things such as log in to your site, create and retrieve a password, show the logged in status of the user, etc.

This need has recently come up with an application I’m developing for the company I’m working for. We have a pretty large web database application built in Cold Fusion MX 7 which we are converting to ASP.NET 3.5 (thank goodness) .

Membership and roles have been included in the .Net framework since vesion 2.0. Although I had looked at the membership and roles providers in ASP.NET before, I really wasn’t familiar with the custom providers you can build on top of the default ones that ship with ASP.NET 2.0. The specific providers in question here are the SqlMembershipProvider and SqlRoleProvider classes, as I’d be needing something that utilizes a SQL database. So this is great, there are providers that I need that specifically relate the .NET controls i’d be using and the SQL database their values need to map to. The problem however, is that by default, these providers will create a brand new SQLExpress database called ASPNETDB.mdb and store it in the .NET directory’s App_Data folder to be used for handling things like user and roles storage and retrieval. This is not what I want. My company already has users, logins, passwords, and even roles that they’ve been using for years, and creating new ones for every user of our system just to accommodate a new coding structure is obviously unacceptable; we have almost 100,000 users! What we need is a way to make ASP.NET’s membership and roles APIs work with the data we already have. This is where custom providers come in.

I’ll get more into this a little later…

finally got it started

January 21st, 2010

I finally started the blog. I’ve been meaning to make this thing happen for so long, but I never followed through.

Thanks to my friends Taylor Anderson @ z3photo.com and Jandro Davalos @ jandrodavalos.com for inspiring me to do this by doing it themselves. Ironically, it took a photographer and a cinematographer doing their thing on the web in order to get me, the developer, to do mine.