There and Back Again : Agile

Old TDD Demo Blog - Digest and Code

hdierking — Sun, 02 Mar 2008 10:24:00 GMT

Several of you have emailed me over the past several months asking if I had a copy of the blog text and/or code that I had mentioned in a much earlier blog entry. As it turns out, a good friend of mine found some old archived versions of the site on an Internet cache and set them over to me. Therefore, I have taken the web pages and compiled them into an XPS document so that you can see the thought progression that went along with building a small application, TDD style.

Additionally, I've updated the code samples a bit. Specifically, I've upgraded the version of NHibernate to 1.2.1.GA - and as such, dropped the use of Ayende's NHibernate Generics library. Also, as I was going through my NHibernate mappings, I realized that I had been pretty lazy with regard to semantic accuracy for collection types - I had pretty much completely used <bag> mappings instead <set> mappings for unordered collections so that I could use IList<T>. Therefore, I cleaned that up a bit. Other than that, the only other thing that I did was update some of the looping and conditional code to use LINQ.

Finally, let me emphatically throw out the "Demoware Disclaimer" - The point of the blog and the code samples was to illustrate the thought process and corresponding code behind using TDD to design a domain model. As a result, everything else in the code is the simplest thing that could be implemented to support the overall goal - and nothing more.

Wow - That Was Annoying

hdierking — Mon, 19 Nov 2007 05:18:53 GMT

So I'm in an awkward place right now when it comes to programming. In addition to the fact that I no longer program on a day-to-day basis (which is starting to bug me a little more than it used to as I'm afraid I'm starting to atrophy a bit), I'm also now up on Visual Studio 2008 - which is really great in a lot of respects - but at the same time is kind of bumming me out. I'm not bummed because of anything inherent in Visual Studio - I'm bummed because Resharper just doesn't really work all that great in it. Don't get me wrong - R# works - but the semantic analysis tools don't yet work with a lot of the C# 3.0 language enhancements - and as much as I tried to ignore the R# compiler errors on things like Linq queries, I finally just got tired of it an uninstalled R#, impatiently awaiting the 4.0 release.

Firstly, let me just say that not having R# is miserable from a refactoring standpoint.

Secondly, losing R# led me down the path to another headache (which is the subject of this post) - I no longer have a VS add-in runner for NUnit. Yes, I know - I could (and probably should) go back and download TD.NET - but instead, I was curious to see how easily it would be for me to just convert my NUnit tests to VS 2008 unit tests. In short, it's not terribly difficult, but getting there was a frustrating journey.

Why? Because unlike NUnit, where a test fixture is explicit in code (and only in code) via the TestFixture attribute, VS tests rely on a second piece of metadata in order to have them run via the VS test manager/test runner. That metadata is not found in the *.vsmdi file - instead, it's actually a property in the project file of your unit test project.

Therefore, if you started from a regular class library project and need to have it recognized by VS as a "test project", open the *.csproj file in notepad and add the following to any PropertyGroup.

The first Guid identifies your project as a test project (the second is the language I believe - feel free to correct me if I'm wrong).

ALT.NET - Trip Report

hdierking — Fri, 19 Oct 2007 06:41:58 GMT

I had the recent opportunity to travel to Austin, TX to attend a meeting of the minds of those who are considered thought leaders in the .NET agile/open source space. This community, in somewhat of an expression of feeling that the general .NET community (as guided by Microsoft) has gone in a different philosophical direction with regard to designing and building software, has aptly elected the name ALT.NET. While the meaning of "ALT" was the subject of several spirited debates, my general takeaway is that "ALT" is simply shorthand for "alternatives". The plural is important here because this community is not defining themselves or their values as the alternative to Microsoft technology and guidance. Rather, at the core, they are more interested in trying to promote the development of leaner, more maintainable software using whatever tools are most helpful to those ends (Microsoft or otherwise). To give you an idea of just how big this community's toolbox is, see the following.

Frankly, I think that the choice of the "ALT" moniker, while not meant to be seen as an alternative to Microsoft (which would actually be contradicted by the ".NET" part), is born out of the general frustration by the community that the tools Microsoft gives developers enables short term productivity and long term headaches - while at the same time decreasing the overall skill of developers and making them dependent on a specific type of tool (e.g. - designers).

The conference was conducted in a format called "Open Space". In this style, there were no formal sessions and no formal presenters. Anybody who wanted to talk about (not necessarily lead) any subject could put it forward to the group and schedule it for a time slot/meeting room. As such, Simon Guest and I sponsored a talk on how to engage the ALT.NET community with the rest of the .NET developer community. From those individuals who attended the session, we were able to identify a few interesting points of feedback.

The community feels that MSDN and MSDN Magazine are stale and sterile, and that while there are lots of "how-to" articles, there is very little content that explains "why".
There was a general lack of awareness about newer offerings from MSDN online - particularly the architecture dev center.
Many of the audience are already avid and well-followed bloggers, and as such were skeptical as to the value-proposition of writing for MSDN Magazine.

As to the first 2 points, I think that there is a lot we can do as an organization to incorporate many of the ideas expressed at the ALT.NET conference - for MSDN Magazine, the first obvious step is to get more people from this community to write for the magazine - which leads me to the third bullet. The point that I kept reiterating to the participants was that while things like blogging and holding ALT.NET conferences are great, they're an echo chamber. People who visit ALT.NET blogs are generally going there because they have already bought into at least some of the philosophy. If you want to really affect change in the larger community, you need go to the community - and MSDN/MSDN Magazine are 2 fantastic ways to go about it. I think that this message resonated well, as, since returning, I have received several article submissions from conference participants.

In sum, this is a community that really wants to see people develop better software, and it was very encouraging to see Microsoft recognizing their contribution to the community by way of the number of Redmond folks in attendance. Going forward, it will be exciting to see both how this community evolves - and how their values and practices have an impact on the larger development community.

If you want to know more about the conference, such as the specific sessions/topics, I covered each day of the conference on my blog - so see the following.

Click here for pictures from the conference.

ALT.NET - Day 3

hdierking — Fri, 19 Oct 2007 04:43:06 GMT

I can't believe that it has taken me so long to get around to writing my concluding thoughts on the conference. That said, perhaps this is a good thing as I have been able to watch the post-conference churn in the blogosphere over the past couple of weeks and can incorporate some of my thoughts on that into my more general thoughts on the conference and on ALT.NET.

Also, in the spirit of being transparent, I will follow this post with a "Trip Report" post. This will be the (verbatim) summary email that I'm sending out to my management - so if you're curious about "what is being said internally at Microsoft about the conference and ALT.NET?", there you go.

First Things First - Day 3

Session - Engaging with the Community (aka - the Simon and Howard show<g>)

Simon Guest, owner of the MS Architect Journal, and I held a session to discuss how the ALT.NET community could engage with the larger .NET community in a way that is practical, tangible, and generally more helpful than the approaches thus far (for an example of what I'm contrasting more to, see my post on day 2 of the conference). Firstly, many thanks to Simon for being much more detail oriented than I am. Using the dry erase board, Simon captured and related the major points expressed by the session participants. This was the perfect complement (or supplement, depending on how you want to look at it) to my style, which is much more of an extended conversation.

Anyway, the basic point that I came into the conversation hoping to convey was (and remains) very simple. While things like blogging and holding ALT.NET conferences are great, it's an echo chamber. People that visit ALT.NET blogs are generally going there because they have already bought into at least some of the philosophy. If you want to really affect change in the larger community, you need go to the community - and MSDN/MSDN Magazine are 2 fantastic ways to go about it.

All in all, I think that there was a very positive response from everybody who attended the session - and I have gotten several emails from people who have taken me up on my challenge to submit article ideas for the magazine.

Session - Language Oriented Programming

I now feel like an adult developer - I've gotten into an argument with Scott Bellware <g>. So those of you who know me know that I'm kind of a language geek - Charles Simonyi is my hero. As such, I was really excited to be part of a discussion on what I thought would be in that vein - and needless to say, I was disappointed when Scott seemed to only want to talk about the philosophical ramifications of doing away with parentheses for method calls in Ruby. I remember having similar conversations wrt JavaScript about 5 years ago!

On a positive note, though, I wasn't alone in my thinking - and a side conversation on language oriented programming got started and actually continued after the meeting ended. Several issues were discussed, but a couple interesting ones that jumped out at me were the following.

Language oriented programming is defined along somewhat of a continuum - the continuum is measured by the definition of language and ranges from defining language as a soluble code library to defining language as a full blown DSL. Depending on your definition, the proximity for the realization of language oriented programming shifts.
We will probably go way too far in implementing custom "languages" before we figure out the best practices - then pragmatism will drive things back to the center (sound familiar?)
In the case of DSL, there are 2 major challenges
- Keeping the language scoped to a narrow domain - the biggest mistake for a DSL creator is letting it grow into another Turing-complete GPL.
- The language integration/collaboration strategy. I am personally REALLY interested in this one.

Closing Session

I shook everybody's hand on a piece of silly puddy!

Note to My ALT.NET Friends Submitting Article Ideas

hdierking — Fri, 19 Oct 2007 02:05:13 GMT

I'm glad that I'm obsessive enough to periodically check my junk folder in Outlook. As I was doing this today, I found emails from Jeremy and Russell about writing for MSDN Magazine. I was able to catch these and respond - however, if you submitted an article to me a while back and have not heard from me, it may have very well ended up accidentally getting trashed. Therefore, please resend to mmsubmit@microsoft.com (this is our official alias for content submission anyway).

Free PDF "Quick Version" of Domain Driven Design

hdierking — Wed, 10 Oct 2007 20:56:47 GMT

http://www.infoq.com/minibooks/domain-driven-design-quickly

ALT.NET Conference, Day 2 - Taking the Good With the Bad

hdierking — Sun, 07 Oct 2007 07:57:27 GMT

Today's post is actually a nice continuance of yesterday's because it deals very specifically with one of the issues that I raised yesterday - specifically the issue of the emerging tenuous relationship between the ALT.NET community and the rest of the professional .NET developer community. That said, today was fantastic - great people, great discussions - and a great show of forthcoming technology by ScottGu. So, in sum, we'll deal with the good and the not so good in tonight's post (IMHO <g>)!

The Not So Good - How to Be a Catalyst for Change In the Community

I went into this session hoping that individuals would come in wanting to share success and/or failure stories related to creating an environment that bought into at least some of the principles of agile - or at the very least became more passionate about writing great software. I also went in expecting there to be a fair amount of Microsoft bashing because of designers, code generation, NIH, etc... (I would mention MSDN/MSDN Magazine here, but that session is tomorrow, so I'll deal with that in the morning). What actually unfolded actually surprised me a bit. So firstly, I should say that there were some success stories shared. J.P. Boodhoo talked about some of the successes he has had with "lunch & learns" - Scott Hanselman and Jay Flowers talked about growing influence exponentially via a style that for this post we'll call "influencing the influencers" (Jay - you had mentioned a book that dealt with this topic - if you're reading, please post the title in the comments). Past those (and a few other) examples, though, the conversation took what I considered a fairly cynical and elitist turn. Earlier I mentioned that I was surprised a bit by what unfolded. What surprised me was that the frustration expressed was not as much directed at Microsoft, but was directed at the general development community. It basically came across as "why won't all these people stop calling me dogmatic and listen to what I'm trying to tell them?!?" Several in the room made the argument that energy should only be expended on influencing those who wanted to be influenced. Huh?? If they...want to be influenced....doesn't that already....nevermind. Anyway, I basically came away from that session with 2 concluding saddening thoughts about many in the ALT.NET community.

They will always be 10 steps ahead of the rest of the professional development community because they are incredibly smart, talented, and motivated.
They will always be frustrated because they are narcissistic.

OK - maybe it was because I drank more coffee, maybe it was something else, but the day got much better as it progressed. Let's move on.

The Good - DSLs/NHibernate

I'm grouping these together because I walked in half way through the DSL talk and I just didn't take that many notes from the NHibernate talk. In fact, I think I'm just going to do bullet points here.

DSL

I hadn't realized that Microsoft released the source code for the .NET Framework Class Library. Totally cool - especially since, as ScottGu mentioned, they shipped it with the symbols, so profiling and debugging into the framework itself is now simple.
There was a lot of talk about DSL support in Ruby. I haven't worked in Ruby so I really can't speak to this - but now I'm curious.
One really interesting comment that ScottGu made, regarding DSLs is to make sure that you have mastered your GPL first, as this will provide you the best platform from which to jump into DSLs.

NHibernate

It was tough to blur the lines between where we crossed into a general DDD discussion and when we were still talking about NHibernate - particularly when we were discussing architectural patterns for DALs, etc...
To the NHibernate team (or someone with the time to look at this on the forge) - It would be totally cool if we could get JIT loading of HBMs, or at least have the option to suppress fail-fast when building the session factory. This came out of a discussion where many in the group were expressing the pain felt when one invalid HBM file caused every unit test to fail (or nearly every view to crash) because the session factory couldn't be created.
On that note, a MSBuild/NAnt HBM validator build task would be nice for plugging into the build.

The Rockin' - ScottGu's Show and Tell

So I haven't really had a lot of exposure to MVC in web applications (yes, I have let the whole RoR phenomenon pass me by - for shame, I know). And as a result, I really didn't see the point of the whole paradigm shift to MVC. I did DVC in MFC and it was a pain - so perhaps I was just avoiding the topic because of past aches, but for whatever reason, this was all new to me. So anyways, Scott demonstrated the new MVC framework that will be available in CTP form pretty soon. Honestly, it's pretty cool. I don't really buy into the argument that MVC is absolutely necessary to cleanly separate the logical layers of your application. I have been doing DDD for a while now and have never run into a major problem with bleeding of concerns on web projects - but maybe that's just me. However, if you're into having leaner, better controlled HTML and, more intuitive URLs, and reduced probability for concern-bleed, the MVC framework is definitely the way to go.

On a related note, let the record show that Scott Bellware is officially my favorite heckler. Scott - whenever you're in Redmond, the drinks are on me!

Back to the MVC discussion, my main next action is to see if I can actually find the bits so that I can get up to speed a bit. Who knows, maybe I'll even take the approach of one of my close friends at P&P and buy a Macbook Pro to play with RoR <g>!

The Confused - DDD

So since this post is getting long, I'm going to sum this session up with a pretty simple statement. Eric - A little help please? There continues to be a great deal of confusion and disagreement in the DDD community about some very fundamental concepts. Examples include the definition of a domain service, an application service, and the very distinctive characterics of DDD that make it different than simply good OOP heuristics.

On a closing note, I have never seen so many iPhones in one place.

ALT.NET Conference - Opening Day..Opening Thoughts

hdierking — Sat, 06 Oct 2007 08:32:00 GMT

I'm currently in Austin, Texas where I'm attending the ALT.NET conference. This conference is essentially a who's who of thought leaders in the .NET agile/open source community - everyone from Martin Fowler to Jim Newkirk to Scott Hanselman to Scott Bellware - the list goes on and on. In sum, over half of the people that you wanted listed as wanting to hear from in MSDN Magazine are attending this conference.

The conference is being conducted in a format called Open Spaces. This is one of the coolest things that I've ever seen in conferences. Basically, after a brief round of introductions, we launched into tonight's main activity - determining the schedule for the remainder of the conference. On a whiteboard was a 2-dimensional matrix - available rooms on the y-axis; time slots on the x-axis. Anybody that had an idea for a session wrote down the idea on a post-it note, presented it to the group, and placed it into a time slot. Once all the slots had been filled additional ideas were placed in a general holding space. Once all the ideas were collected, every individual marked which sessions they were interested in attending and based on this feedback, the schedule was renegotiated. It's worth pointing out that in this type of conference, there is no distinction between presenter and attendee. Everyone just shows up to whatever they are interested in. If you aren't interested in a session, get up and go. If you get sucked into a conference in the hallway - cool. It's incredibly exciting.

So there were 2 comments that I thought were really noteworthy/funny in tonight's opening session. The first was as follows.

"The values support the tools."

I'm not sure I buy this. I think that the values support the tools if you have values that make you interested in values. I think that many developers are perfectly content with using whatever tools they are presented with (e.g. - not going in search of 'better' tools) to do the job that they are being paid to do - solve the problems that they are being paid to solve. I'm not trying to make a value judgement on this group of developers (though I admit, it does kind of sound that way). At the same time, I believe that this is a reality, and as such, focusing on 'instilling values' is not the approach to take if the goal is to change behavior. I imagine that this theme will reoccur throughout this weekend. And that leads us to the second notable quote - ala Scott Hanselman.

"Mort is crying because mommy and daddy are fighting."

So in case you missed all of the conversations from last year on the blogosphere, Mort is the Microsoft persona to describe the group that I talked about in the previous paragraph. Unfortunately, Mort has become somewhat of a derogatory term as of late since he is used more as an accusatory glass that different communities and Microsoft throw at one another when arguing over products, methodologies, etc... you know - 'values'. As a result, Mort is sitting quietly on the sidelines wondering why Microsoft and it's community thought leaders can't get along - and he here's his name mentioned in so many arguments, he wonders "could it be me?"

Why do I care about this? Because I love agile - I love DDD, TDD, BDD, patterns, NHibernate, R#, et al. And I want to introduce more and more of this type of content into MSDN Magazine. However, I think that many of you who read the magazine are not as zealous in programming ideology as many here at the conference - and that's ok. What I refuse to do is allow the magazine to become a forum for the next religious war - to basically take the "C++ rules - VB sucks" argument and turn it into "ALT rocks - Mort sucks". So, for those of you who want more content on all of the cool agile things mentioned above, me too. For those of you who don't care about all of the ideology, that's cool too. I am interested in seeing MSDN Magazine provide practical solutions to all of its readers, no matter where they are on the programmer continuum. I think that a strong case can be made for many of the tools/methods in the agile space - and I want to present them in the Magazine in a way that provides a real incentive for using them. That incentive? Making programming easier and more enjoyable - not buying into a set of values.

Until tomorrow...

DSLs - Not Quite Child's Play ... But Closer!

hdierking — Wed, 16 May 2007 20:53:33 GMT

One of the books I've been reading recently Jack Greenfield's (and several other really smart people) book Software Factories. While I'm not yet sure that I buy into the notion that the creation of software solutions will undergo an industrial revolution of sorts (at least in a measurable timeframe), the thing that really drove me to this book was the discussion on domain specific languages - or "little languages" if you're coming from the UNIX world. I've been following the efforts on DSL coming out of companies such as Microsoft, JetBrains, and Intentional Software for a while now and while I think that model driven architecture is probably too prescriptive as an approach, I do think that there is a great deal of business value to be gained by promoting language oriented programming.

While Jack's book is incredibly insightful, it also (at least for me) can be a pretty difficult read as it takes me back to my old CS days. In fact, much of the work on DSLs reads this way as we are just now starting to try and describe and articulate the theory behind the tools. Therefore, I think it's always fun to see a practical implementation of a "little language".

The Scratch language is a visual programming language for kids developed by Mitchel Resnick and team at MIT's Media Lab. The language allows kids to build software systems that do some very basic - but very real things. What's cool is to think about the next step - when we come to a better understanding of integrating different DSLs to create richer systems. As an example, taking a Scratch application and integrating it into a distribution language would be an easy leap for allowing kids to create simple games that they can immediately promote to the Internet to play with other kids all over the world!

NHibernate Custom Mapping Types

hdierking — Tue, 24 Apr 2007 05:36:00 GMT

(originally posted to Absolute Opinion on June 14, 2006)

As you should know by now, NHibernate is an object-relational mapping (ORM) tool that uses XML metadata files to marshal data between an object-oriented domain model and a relational database. Now, in the majority of use cases, the default support provided by NHibernate will be sufficient for saving and fetching your domain objects. However, there are cases where additional capabilities are required. Fortunately, NHibernate provides lots of extension points. I’m going to discuss 2 scenarios in this article – both of which take advantage of creating custom NHibernate mapping types.

Scenario 1:

You have an implementation of the Type Object Pattern. Simply put, you have a class to represent the type of an object, and then a class the references your type object. The static model looks like the following.

Now, let’s take this a step further and say that your type class takes a pretty large amount of time to construct and initialize. Therefore, you decide to implement a flyweight factory in order to minimize the performance impact on your application in terms of the number of type class instances that must be constructed. Fantastic! Now, let’s look at the ramifications on persistence.

From the object persistence perspective, the problem you are now facing is that you do not want to persist the object state for your TypeClass instance (since you are trying to control the number of instances for that class). However, you do want to persist enough information about the TypeClass instance so that when you load an instance of ActualClass from the database, you can get the correct TypeClass instance from the flyweight factory and apply it to your reconstructed ActualClass instance.

Now in a world without NHibernate (oh what a sad world!), we would create a data access class for ActualClass and add methods for setting and fetching ActualClass instances. Since the TypeClass reference exists outside of the database scope, we would add the association in the data access class. For example, your data access class may have code that looks like the following.

   1:  public static class ActualClassRepository {

   2:    public static void Save(ActualClass actualClass) {

   3:      IDbCommand cmd = null;

   4:      IDbDataParameter param;

5:

   6:      //build the sql command and parameters...

   7:      param = cmd.CreateParameter();

   8:      param.ParameterName = "@typeClass";

   9:      param.DbType = DbType.String;

  10:      param.Value = actualClass.Type.Name;

  11:    }

12:

  13:    public static ActualClass Get(int id) {

  14:      IDataReader rdr = null;

15:

  16:      //build the sql command to and get a data reader...

  17:      if (rdr.Read()) {

  18:        ActualClass ret = new ActualClass();

  19:        ret.Data = rdr.GetString(0);

  20:        TypeClassFactory factory = new TypeClassFactory();

  21:        ret.Type = factory.GetTypeClass(rdr.GetString(1));

  22:      }

23:

  24:      return null;

  25:    }

  26:  }

If you pay attention to the code shown in bold for both the get and set methods, you can see how your data access class might handle the setting and fetching of an object and its associated type object. When saving the ActualClass object, the data access object saves the name of the associated TypeClass object to the database. When the ActualClass object is restored from the database, the name of the TypeClass is retrieved and passed to our flyweight factory where the object instance can be acquired and set on the ActualClass object being built.

Now, this works fine in very simple cases like the one mentioned above. However, most object models have many more complex sets of associations. It is in cases like this where NHibernate reveals a great deal of strength – and it would be advantageous to be able to use NHibernate to solve our type object problem.

Enter the custom mapping type.

In NHibernate, a custom mapping type is a class that derives from either the IUserType or ICompositeUserType interfaces. These interfaces contain several methods that must be implemented, but for our purposes here, we’re going to focus on 2 of them. Consider the following.

   1:  public class TypeClassUserType : IUserType

   2:  {

3:

   4:    ...

5:

   6:    object IUserType.NullSafeGet(IDataReader rs,

   7:      string[] names,

   8:      object owner) {

9:

  10:      string name = NHibernateUtil.String.NullSafeGet(rs,

  11:        names[0]) as string;

12:

  13:      TypeClassFactory factory = new TypeClassFactory();

  14:      TypeClass typeobj = factory.GetTypeClass(name);

  15:      return typeobj;

  16:    }

17:

  18:    void IUserType.NullSafeSet(IDbCommand cmd,

  19:      object value,

  20:      int index) {

21:

  22:      string name = ((TypeClass)value).Name;

  23:      NHibernateUtil.String.NullSafeSet(cmd, name, index);

  24:    }

  25:  }

Having created this class, I can now explicitly map the association between ActualClass and TypeClass as a simple property on the ActualClass mapping.

<property
  name="Type"
  column="TypeName"
  type="Samples.NHibernate.DataAccess.TypeClassUserType, 
    Samples.NHibernate.DataAccess" />

As NHibernate is in the process of saving an instance of ActualType, it will load and create a new instance of TypeClassUserType and call the NullSafeSet method. As you can see from the method body, I am simply extracting the name from the mapped property (passed in as the value parameter) and setting the extracted name as the value of the parameter to be set in the database. The net result is that although the Type property of ActualClass is TypeClass in the domain model, only the Name property of the TypeClass object gets stored in the database. The converse is also true. When NHibernate is loading an instance of ActualType from the database and the finds a property of my custom mapping type, it loads my custom type and calls the NullSafeGet method. As you can see, my method gets the name from the returned data, calls my flyweight factory to get the correct instance of TypeClass, and then actually returns that instance. The type resolution process happens transparently to my data access classes (and even to NHibernate itself for that matter).

Scenario 2:

As a part of your object model, you have a standard IDictionary implementation (Oh my goodness – untyped collections!!! Yea – it still happens sometimes!) that looks as follows.

private IDictionary _values = new Hashtable();

Now, here’s the basic problem with this implementation when persisting to a database. By design, this data structure can contain – well – anything. So how do you persist it to the database in a meaningful way? One technique that can be used is to store the value as a string in one column and store the type identifier as a string in a different column. The problem here is that many times (especially when you think about it from the database point of view) you end up with a clunky object model because there is no real reason to store the type as an additional piece of data. Fundamentally, the database requires 2 pieces of information to make sense of 1 piece of domain model information (value + type). It would be really great if we could hide this splitting and merging of data in the mapping layer…

…and we can – using a composite custom mapping type. Take a look at the following.

   1:  public class Object2StringUserType : ICompositeUserType

   2:  {

3:

   4:    ...

5:

   6:    object ICompositeUserType.NullSafeGet(IDataReader dr,

   7:      string[] names,

   8:      ISessionImplementor session,

   9:      object owner) {

10:

  11:      string val = (string) NHibernateUtil.String.NullSafeGet(dr,

  12:        names[0],

  13:        session,

  14:        owner);

15:

  16:      string valTypeString =

  17:        (string) NHibernateUtil.String.NullSafeGet(dr,

  18:          names[1],

  19:          session,

  20:          owner);

21:

  22:      if (val == null || valTypeString == null)

  23:        return null;

24:

  25:      Type valType = Type.GetType(valTypeString);

  26:      return TypeDescriptor.GetConverter(valType).ConvertFrom(val);

  27:    }

28:

  29:    void ICompositeUserType.NullSafeSet(IDbCommand cmd,

  30:      object value,

  31:      int index,

  32:      ISessionImplementor session) {

33:

  34:      string valString = TypeDescriptor.GetConverter(

  35:        value.GetType()).ConvertToString(value);

36:

  37:      string valTypeString = value.GetType().AssemblyQualifiedName;

  38:      NHibernateUtil.String.NullSafeSet(cmd, valString, index, session);

  39:      NHibernateUtil.String.NullSafeSet(cmd,

  40:        valTypeString, index + 1, session);

  41:    }

42:

  43:    string[] ICompositeUserType.PropertyNames {

  44:      get { return new string[] {"val", "valType"}; }

  45:    }

  46:  }

As you can see, this interface fragment looks similar to that of our regular custom mapping type. However, it has several additional members which allow the custom type to actually map a given domain model value onto multiple database columns. In this example, I have used the type to split the value of my IDictionary object over 2 columns in my database table: Value and ValueType. When my dictionary is persisted, my mapping type converts the dictionary value to a string and then persists that value along with the fully qualified name of the value’s original type to 2 columns in the database. Those columns are identified in NHibernate mapping file and mapped to property names (in this case val and valType) based on the order in which they appear in the mapping file. The NHibernate mapping XML looks as follows.

<map name="_values" access="field" table="Values"> 
  <key column="ID_Parent"></key> 
  <index column="Key" type="String"></< SPAN>index> 
  <element type="Samples.NHibernate.DataAccess.Object2StringUserType, 
       Samples.NHibernate.DataAccess"> 
    <column name="Value" /> 
    <column name="ValueType"/> 
  </element> 
</map>

Again, all of this happens behind the scenes as NHibernate is setting and fetching your objects from the database. All you know is that for any type that you put into the your dictionary, you can expect the same type to be in the dictionary for that item, even after saving and loading it from the database.

In conclusion, I hope that this has illustrated the flexibility that can be found within NHibernate as it relates to some more advanced mapping scenarios. If you have any questions or ideas for custom mapping types, please share!

Designing a Domain-Driven Data Access Layer

hdierking — Tue, 24 Apr 2007 05:35:57 GMT

(originally posted to Absolute Opinion on June 4, 2006)

I had started writing a post about best practices for using the different NHibernate collection mapping types when it dawned on me that I may be assuming too much in thinking that we all look at data access layers in the same way. In fact, I think that it is fair to say that most folks who came through the ADO school of data access were trained to think of the data access layer as little more than a set of helper classes used to connect “business objects” to SQL Server stored procedures.

Now, for those of you who still view the data access layer in the way that I described above, this article is not to convince you that you are wrong (even though you are). However, I think it may be fair to say that you may have trouble fitting what I’m going to describe into your way of thinking.

So let’s start with a few very basic goals for a data access layer (DAL).

The DAL should completely hide the underlying data access technology, whether it be an ORM tool like NHibernate, hand-generated inline SQL, calls to stored procedures, or anything else.
The DAL should not place any significant constraints on the design of the domain model.
The entire layer should be replaceable with minimal impact (or minimal risk for you PM folks).

Now, all of the aforementioned goals can be summarized with one word: decoupling. This is a great word – it’s a word that we keep hearing over and over again with every architecture talk and every article. In fact, didn’t the introduction of component programming give us decoupling without any effort on our parts?

In case you were wondering about that last one, the short answer is – no.

So what should a decoupled DAL look like? In .NET programming terms, the answer lies in the references. Given our stated DAL goals, we need to be able to pull out our entire DAL and replace it with another (say one that persists our objects to and from the file system rather than a RDBMS) without causing any impact on the rest of the system. We therefore can’t have our business layer (henceforth called domain model) having any knowledge that a DAL even exists. This is due to the fact that our domain model is designed to be the very core of our system. The objects contained within the domain model form the basic language that our software system uses to describe a real world problem. Put another way, our domain model is (or, should be) a neutral layer in terms of technology concerns. The last thing that we should want to do is create a dependency on a layer whose sole focus is a technology-specific concern (persistence).

So, getting back to observing decoupling through references, what can we deduce from my tangential diatribe above? Firstly, the DAL assembly should hold a reference to the domain model assembly – the domain model assembly should not reference the DAL in any way. Secondly, all other assemblies that need to interact with a persistent store to get and set domain objects will hold a reference to both the domain model assembly and to the DAL assembly. To pull from the SARK Classic project, such a relationship looks as follows:

Now that we have an architectural view of what the DAL should look like, what should it look like at the code level? Firstly, DAL classes should be defined not in terms of “1 DAL class per 1 domain model class” but rather in terms of domain model aggregates. The term aggregate was defined by Eric Evans in his book Domain Driven Design as follows.

“An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary. The boundary defines what is inside the AGGREGATE. The root is a single, specific ENTITY contained in the AGGREGATE.”

So you may be wondering why the terms “aggregate” and “entity” are typed in caps – well, me too – that’s just the way the book was written.

Let’s apply that definition to the SARK Classic sample project. A golf course has a specified number of holes – and each hole has a par value. However, the unit of change from the data perspective is always the course – i.e. – there is never a time when you would access a specific hole directly – you would always access a hole through the course. Therefore, we can say that the Course Aggregate consists of 2 classes: Course and Hole. That is the aggregate boundary. Additionally, Course is the aggregate root. In support of the aggregate boundary, DAL objects should be defined for aggregates – not specifically for domain objects.

Once you have defined aggregate boundaries, you will hopefully find that persistence concerns can be dealt with at a more coarsely granular scope. Dealing with aggregates rather than objects may also help reduce decoupling even within the domain model. I’ve seen that many domain models have unnecessary associations between objects simply for the purpose of pulling down the entire object graph during persistence. In thinking of persistence in terms of aggregates rather than domain objects, you may also see opportunities to get rid of some of these associations and instead simply create additional query methods on the DAL object for the associated aggregate. This idea is also discussed in Eric Evans’ book, so for additional research on the topic of aggregates, it is a must.

Now, when talking about DALs that are written in terms of a domain model rather than a technology like DataSets, critics typically raise a very good point: Why is this design technique worth losing all of the wonderful support that Visual Studio provides for RAD development? In short, it’s not. A colleague once said something very profound – it was something I was already doing, but I like the way that he said it, so I’m going to attempt to quote him. He said, “Render unto the DAL that which is the DAL’s – render unto the DataGrid that which is the DataGrid’s”. Ok, he was talking about NHibernate – and I’m generalizing a bit more – I’m certain that he will forgive me. If you’re building an ASP.NET application using a GridView, you should use the data source providers in the .NET framework to populate that GridView. Your DAL should not be concerned with dealing with tabular data (especially now that the data source providers are in the .NET Framework). Your DAL is concerned with getting and setting domain objects. See? You can have your cake and eat it too!

Finally, let’s spend a few minutes dealing with DAL design as it relates to NHibernate. Again, I want to quickly reiterate that the DAL design style that we’ve been discussing in no way relies on NHibernate. However, there are some major benefits to using NHibernate inside of your DAL.

Reflection based mapping allows complete encapsulation of object state, as it can reflect over private members.
NHibernate keeps track of the mapped id of an object and can determine whether it is a new object (known as a transient entity) or whether it is an existing persistent object. The NHibernate API then allows you to simply call a method “SaveOrUpdate(object)” – and NHibernate will determine the type of query that needs to be run.
NHibernate keeps track of the dirty state of object members.
For object graphs where there are several associations, NHibernate can be optimized to use outer joining so that only one query needs to be run rather than running a query for the aggregate root’s data, then running subsequent queries for the other members of the aggregate.
Caching anyone?
NHibernate supports multiple RDBMSs right out of the box (or zip file)

These are just some of the many benefits to using NHibernate as your data access technology. Over the next couple weeks we will dive into some of the specifics of using NHibernate. However, like I said at the beginning, I want to make sure that we’re all on the same page architecturally before getting into the details.

Scrum Room?

hdierking — Wed, 11 Apr 2007 08:56:06 GMT

If you're going to do any job, you may as well have some fun with it. Great work Bil!

Team System Unit Tests and Deployment Items

hdierking — Sun, 25 Feb 2007 02:24:57 GMT

Just a quick tip in case you haven't yet encountered this yet. In the course of my development rhythm, I use both Visual Studio Team Edition for Software Testers and TestDriven.Net as test harnesses for my unit tests. This is primarily due to speed. As I'm sure you're aware, the VSTE test engine takes a good bit longer to initialize than TD.NET and because my programming style is very TDD in nature, I like to run my tests more frequently, and from the test code itself. Now, I ran into a situation today where I wanted to do some testing on an Xml schema that I wrote. Therefore, I have the following test.

   1:  [WorkItem(93), TestMethod]

   2:  public void testGetAssetTypeSchema() {

   3:      XmlSchema assetTypeSchema =

   4:        ((IXmlSerializable) new AssetType("temp")).GetSchema();

5:

   6:      XmlReaderSettings xmlSettings = new XmlReaderSettings();

   7:      xmlSettings.CloseInput = true;

   8:      xmlSettings.IgnoreComments = true;

   9:      xmlSettings.IgnoreWhitespace = true;

  10:      xmlSettings.Schemas.Add(assetTypeSchema);

  11:      xmlSettings.ValidationFlags =

  12:        XmlSchemaValidationFlags.ProcessIdentityConstraints;

  13:      xmlSettings.ValidationType = ValidationType.Schema;

  14:      xmlSettings.ValidationEventHandler +=

  15:        new ValidationEventHandler(settings_ValidationEventHandler);

16:

  17:      XmlReader xrdr = XmlReader.Create("Workstation.xml", xmlSettings);

  18:      XmlDocument xdoc = new XmlDocument();

  19:      xdoc.Load(xrdr);

  20:  }

My "Workstation.xml" file sits in the project directory along with everything all of the rest of my code files. I run my test using TD.NET and I get a file IO exception – my Xml file could not be located. Oh – woops! I forgot to change the "Copy to Output Directory" property. This ensures that when I build my project, the Xml file will always get copied into the output directory along with my assemblies. To do this, I select my Xml file in the solution explorer, and look at the properties window. I can then find the "Copy to Output Directory" setting and change it to "Copy always".

Now, at this point, my test will run just fine with TD.NET because that test harness runs my tests "in place". However, VSTE creates an entirely different folder structure to manage test runs and test results. Therefore, when I run my test with VSTE, my test fails again. To correct the problem, I need to add one more attribute.

[WorkItem(93), DeploymentItem("Workstation.xml"), TestMethod] 
public void testGetAssetTypeSchema() { ... }

The "DeploymentItemAttribute" will cause the VSTE test engine to copy my Xml file from the assembly output folder to the test deployment folder – and therefore the relative path I specify in my test still works flawlessly.