Karl Seguin

Johan,
Thanks for the feedback. Honestly, I never even thought about it (which I realize highlights the problem you'd like to see addressed). I'm not even sure I'd know what to talk about.

Would you say that people who do server-centric programming (be that websites or web services) generally worry less than people doing desktop development? I mean, assuming the server is hardened, I don't have to worry about someone modifying my libraries, invoking private members, or manipulating system memory. The security I do worry about tends to be application specific - roles, permissions and input validation. Even the security protocol is pretty high level - SSL or some type of asymmetric key exchange.

I guess what I'm saying is that even though I'm more than willing to wing my "expertise" on some topics, security isn't one of them.

If you have any resources for me, I'd be more than happy to learn.

Never used it, so can't say for sure, but I'd bet you're pretty safe. Testing frameworks are pretty straightforward in my experience.

Humm...I do agree that is the hardest part about learning to unit test. When you first start up you end up with a lot of little test that seem to add no value, and some really big ones that seem overly complicated.  I did write a few blog posts about my adventures in TDD that I think might be useful: http://codebetter.com/blogs/karlseguin/archive/tags/TDD/default.aspx but aside from that I neither have a really good book or any type of resources.

I know that there's some backlash starting to grow about interaction testing, but I still think the best think to do is learn a good mocking framework (RhinoMocks) and start with some interaction testing. This will first and foremost immediatly highlight tight coupling in your code, which you then must fix using some type of IoC (StructureMap's Dependency Injection comes to mind) and with that done you start to see far more meaningful tests.  The Ebook covers it all, although it's high level and the end to end code examples are a little few and far inbetween.

MattV: this is a pretty simple scenario for NHibernate. To answer your second question, when you create a mapping in NHibernate, you can tell it which access and naming strategy to use. So you could tell it to access FirstName and LastName via a field using the "camelcase-underscore" strategy. NHibernate does require a default constructor (no parameters) to be present, but it doesn't have to be public. I consider this acceptable since it doesn't require a change to your API (I think RhinoMocks requires a default constructor on Partials anyways, and if not that, something else, so it tends to be requirement for most framewoks).

As for the first question, NHibernate handles this via composition, and the Name example is actually the one they give in their documentation (http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html_single/#components-dependentobjects).

I think I've had trouble mapping on one or two occasions. Typically, the cause of that has been my own ignorance about NHibernate, or a design decision that ended up not being the best. If you use it enough, and depending on what you do, I do think you'll run into situations that no longer map nicely. I guess in those situations, you hand roll your own mapping, or move to an even more flexible O/R mapper (never used it, but i think iBATIS is what people who recommend in those situations).

MattV:
I was just looking at some older code we wrote and thought it might alleviate [some of] your concern. Essentially:

public abstract class NHibernateDataStore : IDataStore
{
    public User GetUserByCredentials(string userName, string password)
    {
          _session.CreateQuery(from User where UserName ....).UniqueResult<User>();
    }  
    public abstract ProductResult SearchProducts(...);
}
public class MySqlDataStore : NHibernateDataStore
{
     public ProductResult SearchProducts(...)
     {
          //hand coded sql, sproc, whatever
     }
}

95% of the logic is within the NhibernateDataStore, but some queries needed special optimizations (after profiling) or were just too complex, so were hand-coded the SQL within the MySqlDataStore.

This seems like a win-win, you get the quicker development time, with no constraint on flexibility. NHibernate will only box you in if you let it - but it's pretty easy not to get yourself in that situation (and pretty easy to get out of it anyways).

Would that address part of your concern or is there something more to it? I certainly don't advocate NHibernate in every situation, but I do believe that people who aren't familiar with it will probably never end up using it even when it's the perfect fit.

I think the snarkyness is pretty much gone by chapter 2, which isn't surprising since chapter 1 specifically deals with ALT.NET

Just wanted to say thanks for the kind comments about the book. Hope it's useful

Cheers,
Karl