Geeks With Blogs
A Curious Mind #tastic

[This post is long, and is mostly a brain dump]

I recently started a bender of coding where I am trying to move all of my transaction management code out of my Controllers (MVC controllers) and in to a more appropriate place. But since I am striving for a POCO model where in the hell can I put this code and still seperate all of my concerns?

I start digging into "POJOs in Action" and see that Chris uses a class called a Facade to manage this transaction junk. It sits between the view logic and the domain model (business logic). Well even thought it is a new layer of classes for my code base at the moment I am going to have to write this layer at some point if I am going to seperate out my transaction code. This new layer will make it super easy to declare transaction boundaries, what about session (NHibernate Sessions that is) boundaries? It could make going from Web to Windows controllers easier too. hmmm.

So now my call tree is going to go from [Controller => Domain Model] to [Controller => Facade => Domain Model]. How does this relate te MVC and MVP architectures? What do I call these Facade classes (UserFacade and LeadFacade just plain suck)?  UserContext, UserWhat? argh. I wonder if my new book will help out at all?

Ok so it will be no surprise to those that know me that I let myself get hung up on naming in a big way. But this stuff is important to me. So lets look at the name of Facade. Here I think of the Facade pattern, which works for me at some level because this is what the Facade pattern is all about. Creating a coarse API for some more complex/finer-grained sub-componets(ie objects). But in this case where we are manipulating persistant data, not transient data and the name just feels wrong, I want a more specific name. I want a name that combines Facade and my concept of an API. (UserApi? hmm kinda dumb sounding) The Portland Repository makes mention of these Facade classes being something of an Adapter pattern which reminds me of another article about adapters and this related post as well. (UserAdapter, no) (UserPort, no)

Ok, so what if we take a clue from the BDD (NSpec and RSpec) people and think about things in contexts? UserContext (no), but what about UserManagementContext (better)? This strikes me as similar to use cases but I can't recall why. But I am starting to dig the Context name, I think a little more work might just get me there. Ok, so didn't really help, but why do I need to have a suffix at all? Just put all of these classes in a sub-namespace that we can call Contexts for the moment. I like that. I wonder how all of this will fit into my jacked-up, dream like, REST pure application framework?

What I really like about the use of this contexts stuff is that it seperates you from testing. I can't remember where I read this now, but with BDD and TDD you shouldn't limit yourself to one TestFixture per Class, and for me this is where BDD really woke me up. You have contexts like UserIsInactiveContext where you try to perform various actions where the user object is inactive. Please note that these contexts do not convert one-for-one to my POCO contexts. (This leads me to believe that I need further refinement in my naming.)

How do these Use Cases / Contexts fit into the POCO Domain Model? Well lets go back and look at Domain Driven Design and see what if anything Eric Evans has to say. Well nothing jumped out at me, other than maybe I am looking at a Service class. However the new book arrived. I will stop this post and add more after some reading.

Posted on Monday, August 28, 2006 6:52 PM | Back to top

Comments on this post: A better name for Chris Richardson's Facades

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Dru Sellers | Powered by: