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.
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).
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).
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.