Analyzing S#arp Lite - Tasks

this is a review of the s#arp lite project , the version from nov 4, 2011.

so far, we have gone over the general structure and the domain. next on the list is going over the tasks project. no idea what this is. i would expect that to be some sort of long running, background tasks, but haven’t checked it yet.

unfortunately, this isn’t the case. tasks seems to be about another name for dal. and to make matter worse, this is a dal on top or a repository on top of an or/m.

and as if that wasn’t enough to put my teeth on edge, we got some really strange things going on there. let us see how it goes.

basically, a cudtask seems to be all about translating from the data model (i intentionally don’t call it domain model) to the view model. i spoke about the issues with repositories many times before, so i’ll suffice with saying that this is still wasteful and serve no real purpose and be done with it.

this transferformvaluesto() is a strange beast, and it took me a while to figure out what is going on here. let us look in the parent class to figure out what is going on there.

let me count the things that are wrong here.

first, we have this istransient() method, why do we have that? all we need to do is just to call saveorupdate and it will do it for us. then the rest of the method sunk in.

the way this system works, you are going to have two instances of every entity that you load (not really true, by the way, because you have leakage for references, which must cause some really interesting bugs). one instance is the one that is managed by nhibernate, dealing with lazy loading, change management, etc. the second is the value that isn’t managed by nhibernate. i assume that this is an instance that you get when you bind the entity view the action parameters.

nhibernate contains explicit support for handling that (session.merge), and that support is there for bad application s. you shouldn’t be doing things this way. extend the model binder so it would load the entity from nhibernate and bind to that instance directly. you wouldn’t have to worry about all of this code, it would just work.

for that matter, the same goes for validation as well, you can push that into nhibernate as a listener. so all of this code just goes away, poof!

and then there is the delete method:

i mean, is there a rule that says “developers should discard error information as soon as possible, because it is useless.” i mean, the next step is to see c# code littered with things like:

catch(exception e)
{
   delete e; // early release for the memory held by the exception
}

the one good thing that i can say about the cudtasks is that at least they are explicit about not handling reads, and that reads seems to be handled properly so far (but i haven’t looked at the actual code yet).