Mike Nichols - SonOfNun Technology

No Mo Here

2007-01-08T21:26:00-06:00:00

No blogs are getting posted here...update feeds to http://blogs.chayachronicles.com/sonofnun/Rss.aspx or swing by the site at http://blogs.chayachronicles.com/sonofnun/Default.aspx. See you there :) MIKE

Moving Day - Feeds, Update Thineselves (both of you)

2006-10-04T11:13:00-05:00:00

We've moved

New blog found here at http://blogs.chayachronicles.com/sonofnun/Default.aspx

RSS is here at http://blogs.chayachronicles.com/sonofnun/Rss.aspx

Thanks to GWB for parking me here for a spell :) MIKE

When Design Decisions Aren't

2006-09-30T12:29:00-05:00:00

I've been working exclusively alone on a project for a while and have as much liberty as any developer could hope for. I'm a blessed man. Nonetheless, I have tried to kind of "pretend" like I am working in a team environment that has regimented deadlines. This is mostly due to integrity and partly due to prevention for laziness...how easy is it to constantly be researching solutions without implementing them?

There was a necessary period of growth in skill sets that had to occur and while I certainly haven't 'arrived' at some point the rubber has to hit the road and instead of striking out to google for an answer first, there must be some confidence on the toolkit that has been developed. A car has to at least be moving before turning the wheels even in the right direction will make any difference.

So design decisions whether regarding overall architectural structure or about simple object creation aren't strictly design decisions, but are really business decisions. Maintainability is almost at the top of my list for development ; partly because it's just fun to meet the challenge, but also because I work alone and I could be buried with feature requests if I am not careful to write robust, scalable code. Still, this goal has a way of stalling design decisions if you're not careful.

Realigning my thinking into Test Driven Development has largely stumped this phenomenon. Most importantly because TDD isn't about the tests, but meeting requirements in a iterative, thoughtful way.

An example of this came up for deciding how I am going to query my DB using NHibernate as my OR/M. Now, I am using an IRepository for controlling access to the NHibernate implementation of data access and this brings along a whole sweet suite (excuse me) of tools that are a snap to use. I need to create Query Objects to get the data I need in my domain, but do I really want to wrap so much that NHibernate already does for you? For example, do I need to wrap every ICriteria implementation with my own custom implementation to avoid the dependency on NHIbernate's API?How far does one take isolating a domain from specific implementation of these tools?

There seem to be at least three options:

Have more specific IRepository<T> implementations that expose methods like "GetCustomerByNameAndGender(string name, Gender gender)", perhaps in CustomerRepository:IRepository<Customer>
Create an Object Query language as I go that accepts calls maybe with fluid interface calls like .Where(PropertyName name) and so on
Respect the Single Reponsibility Principle and use NHibernate's API within the Domain, but only within query objects.

The first option really just moves the complexity into different area. Maintaining a million little methods really misses out on the joys of Object Oriented thinking where you can treat tasks as things and have adaptable code. The second option is tempting at first, but this is where the business man in me has to speak up and question the wisdom in this route. Do I really want to write a parallel Object Query language just for the sake of independence from an external tool's API? I think this is called "not created here" (or something like that) syndrome, right?

So, after weighing my options, I very simply refactored my implementations of IQuery<T> to use the rich NHIbernate API and my Domain Entities use these objects that fill a collection of ICriteria objects, IProjection types and so on. MY IRepository<T> accepts any object of type IQuery<T> and returns the results I need. If I ever need to switch to a different OR/M provider I'll have to write implementations of IQuery<T> that speak that ORM's language. Really, if I am making that kind of change to an application, this level of adaption seems acceptable.

One tool that can keep these changes from affecting my service layer is some kind of Dependency Injection container that gets the appropriate instance for me at runtime. So instead of instantiating IQuery<T> implementations directly from, say, a higher service layer, I can invoke Castle or Structure Map or whatever to get the instance that I configured. These kinds of tools are perfect for these situations.

OK ...back to coding.

Isolating NHibernate Logging

2006-09-29T07:58:00-05:00:00

I am sure everyone else has already figured this out but thought I'd jot it down here.

I wanted to isolate all messages being sent from NHibernate to its own logging file. NHibernate has lots to say during its operations and often the messages it delivers are the only way of tracking down some obsure error since sometimes the exception messages in NHibernate are...well, wanting. After poking around the forums and trying out a few methods, here is how I finally split my NHibernate logs from the rest of my application logs.

The Configuration

For simplicity, say I want just two log text files produced, system.log and nhibernatelog.log. Look over the log4net configuration and Ignore the Console and AspNetTraceAppenders below:

</layout>

</appender>

</layout>

</appender>

</layout>

</appender>

</layout>

</appender>

<root>

<appender-ref ref="AspNetTraceAppender"/>

<appender-ref ref="Console"/>

</root>

<appender-ref ref="NHibernateAppender"/>

</logger>

<appender-ref ref="NHibernateAppender"/>

</logger>

<appender-ref ref="SystemAppender"/>

</logger>

</log4net>

The primary points of interest are:

I do not have my SystemAppender or my NHibernateAppender inside the <root /> element. Doing so resulted in duplicate entries
The 'name' attribute on the <logger/> element is important. Take note.

Start 'er up

To get things wired up when the application starts, add this to your global.asax in the Application_Start section:

log4net.Config.XmlConfigurator.Configure();

Logging to 'system.log'

To get a reference to my 'system' logger, i just have to use the following:

static ILog logger = LogManager.GetLogger("System");

Notice that I am referencing the logger by its name ("System") in the <logger/> section above. Then to write out to the file, just this:

logger.Debug("Writing Debug Message");

Logging to 'nhibernate.log'

The important thing to understand about controlling logging for NHibernate is that it writes using the following call:

LogManager.GetLogger( Type or string )

Check out this forum post for an explanation of the implications. I snagged the 'logger' setup from this post.

What this means is that the <logger/> element in the configuration will need to have its 'name' set to 'NHibernate' since that is how it is called...any other name NHibernate just won't recognize and logging won't happen.

Note, too , that the configuration above is only logging the SQL (NHibernate.Loader.Loader) sent to the DB and error messages. This helps sift out the rif-raf that I am not real interested in usually.

Once these have been all set up I was successfully logging to the right file. Here are the posts that helped me:

General log4net configuration with NHibernate
Seperating loggers and how NHibernate logs

I Hope this helps another NHibernator!

NHibernate Class Mapping With Generic Parameters

2006-09-24T20:36:00-05:00:00

I needed to implement a component that uses generic parameters. Documentation is sketchy on NHibernate so thot I'd jot it here. I *stole* an IRange implementation from someone and needed to use it for a date range within a class.

</property>

</property>

</component>

Note the `[genericTypeParameter] syntax. Here's how we map it. Be sure you have a default constructor! The exceptions thrown by NOT having a default constructor are riddles at best.

NHibernate Parameters and Escaping Special Characters in HQL

2006-09-19T11:48:00-05:00:00

I am sure I everyone else knows this by now, but I wanted to jot a note. When you are passing strings to an HQL query, it's best practice to assign those strings to a parameter (named or positional) and let HQL escape the special characters for you. So it would look like this when searching by a Name and Distinction tag on an Entity:

StringBuilder queryString = new StringBuilder();

queryString.Append("from Entity e where e.Name= :name AND ");

queryString.Append("e.DistinctionTag = :distinctionTag ");

try

{

query.Match = Session.CreateQuery(queryString.ToString()).SetString("name",query.Name)

.SetString("distinctionTag",query.DistinctionTag).UniqueResult() as IEntity;

}

catch (NonUniqueResultException)

{

query.Match = new NullEntity();

}

return query.Match;

The call to .SetString() is where we assign our parameters to our string values. This works for matching Custom Classes and even Custom Type Properties as well. Sweet.

Further Info

Hibernate in Action pp. 245-247

Patterns, voicings, and rudiments

2006-09-14T16:40:00-05:00:00

For the first 14 years of my professional life, I was a touring musician with a Master's in Music Performance in percussion. By the grace of God, I've been moved along into a fun profession of Software Development. For the most, I've been a lone ranger and have had to learn everything on my own, which is fine since I enjoy problem solving. As I've matured (ok..I am still in Beta :)) in my 'skills' - not the numbchuck kind - I've seen many parallels to music composition/arrangement and development. This isn't a new idea I know, but one struck me tonight.

I needed to add a new field to distinguish records on an object. Now, in the past I'd add the field int the Db and then have to think about ALL THE PLACES I HAVE TO ADD IT and any functionality to accomodate it. This simple requirement COULD break my whole dang domain if I had built spaghetti code. However, as I've built my domain, certain styles and patterns have emerged that let me ALMOST be mindless in solving problems like these. Since I had implemented solutions using certain software patterns, I could simply look into the domain and let IT tell me how to code. Kind of a pattern-of-patterns thing.

A parallel to this in jazz piano is voicings on a keyboard. Pianists like Bill Evans, McCoy Tyner (tho I shudder to put them in the same sentence), Red Garland and so on voiced chords in their unique way, but did so usually from a common way of thinking about how a chord SHOULD be voiced. Voicings, by the way, are the notes you select to play a type of chord...so McCoy might leave the third out to get a kind of earthy sound, but Evans might add upper partials to a chord to give more of a shimmer. The point is, IT'S THE SAME CHORD but they have a bag of tricks to drawn on so they don't have to freak out everytime a new chord comes along.

Patterns in software are like that I think and actually make the process of development more fun. Not because you can use fancy terms .. they are just ways to solve problems. But in the end, I feel like I have expressed something in a way I WANTED to express it, as opposed to throwing datasets all over the place and then feeling lucky that I just got the data back and forth to the user.

Builds that make my eyes bleed and the assemblies that cause them

2006-09-13T09:16:00-05:00:00

Lately, my ASP.NET 2.0 app has been taking so long to build I have been going crazy. I came across this post at ScottGu's blog that had a possible cause for suddenly long build times. I have about 20 projects, but it's hardly a massive site.

I had some problems that I just kind of put up with a while ago where an older version of Iesi.Collections.dll would appear in my /bin folder of my web root and I have been running the NHibernate alpha 9that uses version 1.0.0.2 of Iesi.Collections). Anyways, it didn't occur to me that this was cuasing the problems ScottGu is discussing in his blog. But I couldn't track down WHO was bringing in the wrong assembly. Finally, I remembered that some code was using Ayende's NHibernate.Generics ... AHA! This was built against the older Iesi collections assembly so that was the culprit.

So since I am moving to the new NHibernate that supports generics anyways, I yanked all the references and code out that use the NHibernate.Generics library and my build times got back to normal and my sanity has slowly begun to be restored...

Validation With Bows and Arrows or With Battle Axes and Swords?

2006-09-12T09:42:00-05:00:00

One of the things that requires a realignment in thinking when moving away from RAD development tools as a means of solving business problems into a Domain Driven approach is where to put validation and how to provide meaningful messages back to the user when something goes wrong.

It seems to me that a good indicator of an anemic strategy for validating data is lots of work being done with validation controls and checks at the presentation (view) level. That doesn't mean that careful validation and thoughtful strategies at this layer are useless, but rather we shouldn't DEPEND on this layer to guard our datastore from bad data. Personally, I love using Peter Blum's Validation Controls for my web pages because he has taken great pains to create a rich set of controls that do one thing VERY well...validate at the client-side. Still, before I implemented a rich validation scheme across my layers in my app, I was spending TOO MUCH time with these controls to do work that belonged in the Domain Layer.

A neat approach to validating entities in the Domain layer can be found on JP Boodhoos site where he has a thorough explanation of a kind of reactive validation scheme. It's simple and easy to implement as well as flixible, should you want to apply different rules on the same entities.

After being careful in validating data and implementing strategies in the 'lower layers' I discovered that I had to do very little to guard my user's input from garbage data. All of a sudden, I didn't have to have a ton of validation controls checking conditional comparisons or making sure data was complete before posting because the thoughtfulness that was applied to the domain layer bubbled up to how I designed my User Interface strategy.

So for me, when I find myself having to accomodate complex rules in the User Interface, I need to take a step back and see if there is some insight in the Domain Layer that i haven't gotten yet...for example,

Is there YAGNI lurking in my design that might simplify things vertically across the layers?
Did I let my own business specs creep in, or are my requirements actually coming from the stakeholders?
Am I building my User Interface TOO SOON? Maybe I need to understand my domain better if I am adding and deleting controls like crazy.
Am I relying on textboxes with elaborate javascript do things that CODE should do in the layer beneath?

These are good questions to ask when i am sticking a million validation controls on my page.

I kind of think of clientside validation like the guys with the bows and arrows on top of the wall around the city when the Orcs are marching in with their bad typing skills. They can take out quite a few of the bad guys, but really the heart of the protection is going to take place by the fellas in the Domain layer with their swords and magic wands. The women in my database are relying more on the guy with the battle axe than the guy with the slingshot.

I'm sure I don't get it about the ObjectDataSource control

2006-09-11T13:32:00-05:00:00

I guess I'm confused about the ObjectDataSource control. the SqlDataSource control is a non-issue for me since I'll *never* build an app that puts a view dependency on my database schema, but I see alot about the ObjectDataSource control in the Nhibernate forum.

It's been a while since I actually wrangled with the ObjectDataSource control since I didn't see what advantage trying to get it to wireup to my model this extra control would bring to the table. What is so different about simply binding to a Repeater control? Two-way binding I suppose is the answer, but typically I communicate with a service layer on top of my domain entities since I rather protect my domain entities from upper layers, so by the time i get done wiring up the CRUD events in these new ASP.NET 2.0 controls, did I save time from simply iterating over a repeater and passing the values to the appropriate service for processing?

I'd love to see know what I'm missing since so many developers seem to be spending time extending these controls that, at least from what i can tell, expose an app's Domain layer to bad practices and creates rigid dependencies between the view and it's data source.

What you tink sensei?