Scott Stewart

Partial Class usage

My favorite use of partial classes so far...business object data access code.

In .net 1.x, I often coded my data access layer directly within my business objects. While I was never 100% comfortable with this, it often outweighed my other choices when architecting a project. In my mind, part of a business object's behavior is persisting itself. However, there is always the fear of tightly coupling the BO to a given persistence medium, and then needing to switch persistence mediums. I often find this more of just a good layering question in general, and think the number of times a business objects persistence medium is actually changed is pretty negligible. Keeping the BO and Data Layer as separate classes (and/or) assemblies seems like a better answer to most people who think about these things. However, the problem comes down to how the data is "squirted" into the BO. I say squirted, because if possible I would like the data to come right off a data reader onto my private member variables. If the DataLayer is a separate class (or assembly), then good OOP says that it shouldn't know about my BO's private parts. And if my data layer is just going to return a data reader, then well there is really little need for it to be a separate class or assembly. I would rather see the reader explicitly opened and closed within the scope of a single method call and not handed off by a separate class. Also, if the data layer has to stuff the data into another container (say a separate structure, or <cringe>data set</cringe>), then I've just made a copy of my data and perhaps instantiated a few objects along the way. I only rambled on here because I often get negative feedback when I even comment on why I like my data access code to exist in my BO. But like I said at the beginning, I too have never felt 100% comfortable doing this (despite being convinced of it's merits.)

Well partial classes to the rescue. I now am 100% * convinced, thanks to partial classes. Now I can create a business object assembly with a folder called BusinessObjects and a folder called DataLayer. Inside each folder I can create part of a partial class called Employee. The part of the Employee class in the BusinessObject folder does not need to know anything about my persistence mechanism. It does not have a single System.Data.SQLClient.xxx statement. My other part of Employee in the DataLayer folder provides the Employee CRUD directly against the Employee's private parts  member varialbes! This is really is the best of both worlds. The data access code is now layered into separate .vb files and if the rug gets pulled out and we need to switch from the “S” db to the “O” db, then we do not impact any code files other then the CRUD specific files written in the DataLayer folder. At the same time, we haven't exposed the Employee's private member variables to any other classes, and we can use the fastest means of getting this data into the BO, which is streaming right off of the reader without any additional copies. I like it.

*100% convinced = In my ever evolving quest for design zen, over the next 3 or 4 minutes, for the purpose of an academic exercise, this seems pretty cool.

Disclaimer – I am not actually suggesting that it is a best design practice for a BO to contain actual sql statements, and/or connection management, it all depends on what is being built and the context of the larger architecture. I am however suggesting that I do prefer a BO to be self-containing of its behaviors, part of that behavior is generally persistence. However, the actual persistence code in the BO (and in the partial class for the purpose of this blog) might be simply responsible for calling upon the respective DAL, Data Adapter Layer, etc. I just much prefer:

            MyBO.Save

           Over:

           myBOFactory.Save(myBO)