I am one of those who have really hard time talking generalities. Mainly because lacking a frame of reference usually cause me to try to spin in all directions at once, and Depends is a really bad way to formulate an argument. More often than not, a concrete example, hopefully backed with a code sample that can be dissected, is much more valuable, simply because it focuses the discussion on the subject at hand, instead of scattering it over all the possibility matrix.

The other problem with just talking is that words are cheap, and it is fairly easy to speak in such general terms that the conversation will be meaningless. I got burned really bad on the real world with overly general discussions, and now I mostly tend to drive people crazy by asking more and more questions with regard to the implementation details.

Strangely enough, I don't have the issue of going from a mess of details to an overall view of how things are combined.

Scott Bellware has a post about Responsible SRP, he presents the Ruby's idiom of skinny controller & fat model vs. the .Net one of a service layer. He links to this post from Jamis Buck, which explains the Ruby concepts much better. This is also something that is annoying me about my current application, Rhino Igloo doesn't really provide the same level of separation that I consider essential, and as a result my controllers are doing way more than I wish them to. I probably should have broken at least some of them up to services.

I find myself troubled, because while I agree with all that Scott says in this post, and most certainly with Jamis about the overall direction, I can also see the scaling issues of this approach.

The problem is that when you have even a moderately large application and you keep pushing things to the model, it will go beyond fat, it will be obese. You can see some of the tricks to manage it here (I was surprised that I was able to follow them, actually, very neat), but this is most assuredly something that the RoR crowd has already reached.

Let us take the example of the User model, and assume that I would structure my application this way, I don't see it working. My IAuthorizationService has roughly 25 methods already (I am thinking of breaking it up, that is too much), and trying to put them, plus the IAuthenticationService and the various things that the User already does into the User model would create something that would be hard to follow. It certainly wouldn't be in keeping of SRP.

Another approach is to use mixins in Ruby to separate the functionality into different files and mixed it into the User model. I don't really like it, but that is perhaps a matter of taste.

Again, another matter of probably biased conceptions, but I truly like it much better when I can wire up another implementation rather than start modifying code when I need to make a change to the code. My ideal would be a lot of very small classes, all collaborating in order to get some result. This, to me, gives a lot of flexibly and power when I come to utilize them.

I would be interested in getting response from the Ruby community, what happens when the model get too big? How do you break it up then?

Leon is talking about the way Microsoft Regional Events are handled, interesting reading. We don't have those in Israel, and in the last Microsoft conference ( I took part in it ), we built our own talks, from our own experiences.

When you are thinking about investing the time in coming to an event, there is nothing quite as annoying by being shown something from marketing. That is a waste of time for most people.

The Israeli mind-set is such that 2,000 people can just leave the TechEd keynote talk if they feel that it is wasting their time. Marketing is a waste of time and it shows that your product is (a) lacking in concrete exciting features (b) you are not respecting the intelligence of the audience.

Soren seems to have detailed notes on a lot of the sessions, I already pointed out his coverage of my DSL talk, but he also covered the talks that Hamilton and I did.

• JAOO 2007: Painless Persistence with ActiveRecord by Oren Eini and Hamilton Verissimo
• JAOO 2007: MonoRail, Building Maintainable & Testable Web Applications by Oren Eini and Hamilton Verissimo

Damn, but that is a good book. A different style than most of the other ones, with a lot more investment in characters than in actions, but very good nonetheless. Highly recommended.

Finished it in one sitting, and already want more, but that would be out in 2008 :-(

I just bought Empire of Ivory, in both ebook and audio book format.

It came out four days ago, and I can't believe that I let four days pass by without getting that.

Yes, it is that good.

I was just getting ready to listen to  Black Powder War, the third part of this series, but with changing times comes changing plans.

Now I intend to read the ebook, hopefully this will take up the rest of the night only, and then listen to Black Powder War and then to Empire of Ivory as an audio book.

I don't have Throne of Jade as an audio book, the story was masterfully told, but I didn't like all the PITA politics that went there, too realistic and far too close to stuff that I had to deal with in the past, so I am skipping that.

I really enjoyed His Majesty Dragon as both an ebook and an audio book, however. I usually don't re-read books at those intervals, but Naomi is a very talented writer. And I am looking forward to that.

Right now I have finished listening to We Few from David Weber again (started on the flight, actually), and I am really wishing that this story had more books in it, there are at least two that I can think of.

Now I just need to get through some Brail bugs before I can dedicate myself to truly masterful story telling...

Manuel Abadia has some criticism on NHibernate that I wanted to respond to. First things first, though, it seems that I have been hasty in my response to a problem that Manuel reported, NH-1123. I really don't like it when other people do it to me, and I would like to apologize to Manuel for treating him in a manner I don't wish to be treated.

 As an aside, I have created a new bug on the JIRA, with a bit more focus on the underlying problem. This bug has now been fixed, and I would like to thank Manuel for (a) finding it, (b) persisting even after I wasn't as attentive as I should. Interesting bug, by the way.

He had several other things to say, which I want to respond to in details:

1) It is heavily tied to the java version (Hiberante), so a lot of the request and/or enhancements are ignored. If the java version is not going to add it, probably it will not be added to NHibernate.

 I wouldn't say that, NHibernate is focused on bringing us up to par with Hibernate, but that is certainly not saying that we aren't going to add things that Hibernate doesn't have. Right now, MultiQuery and MultiCriteria are stuff that Hibernate doesn't have and we do, and there are others.

At the same time, if a feature request is something that we can either develop from scratch or port from Hibernate, we would rather bring it from Hibernate. The main reasons are to make it easier to use documentation, built on already fixed bugs, maintain knowledge, and more.

2) Hibernate was started in 2001, and was designed to overcome a lot of the ORM problems. During these years, it has solved a lot of those problems, but other still remain and they can’t be fixed without heavily changing its design.

There are certainly things that I would change with NHibernate/Hibernate if I were able. One of the things on the very top of the list would be to turn the entire internals to AST manipulation and delay the actual generation of SQL to just before executing the query / command. We are working on that, actually. And you are more than welcome to join in and help us do so. And yes, I do mean you, personally, dear reader.

I would be interested to learn what the other problems are, by the way.

3) Even if it is extensible, the IInterceptor interface does not expose all the events that can be interesting to capture (For example, events after loading, updating or deleting data). The only way to handle that at the moment is to implement the ILifecycle interface by the entity itself, losing entity transparency.

Fabio Maulo has been doing tremendous amount of work on this very topic, and NHibernate 2.0 will have the full power of events and listeners from Hibernate 3.0. Most of the world have been completed, and can be found on NHibernate trunk, it opens quite a bit of possibilities.

4) No paging support in some nontrivial scenarios.

As I said, the bug was fixed, but even without that, I would still say that this is not correct. There are quite a few ways that you can do paging in NHibernate, the default approach is not always the best one.

5) There is no support for retrieving all the data at once for hierarchical queries

Here is one example of how to do just that :-)

Okay, that was cheating, since it used native SQL, but that did worked through NHibernate, and you got live entities back from it. No, NHibernate has not native support for doing hierarchical queries, and to support them we have the prerequisite of AST based internal, most probably. (At least the way I think about them)

There is also multi queries, which is what I use to do hierarchies all over the place, mainly because they are far cheaper than a single hierarchical query in real world scenarios (7 tables representing hierarchy, in my case).

To surmise, I would like to mention that NHibernate is an open source project. By its very nature, you are able to go into the code and fix things yourself! NHibernate's codebase is fairly big, but it is also well partitioned, so you are going to find it much easier to work with it than you would expect by simple size estimates.

If you have a problem, by all means, please report it, but do give a try at fixing it, that is going to be easier than you imagine.

Usually when I start a system, I want to focus on the shortest scenario that would bring me a live system. That is usually the login page, since that is almost universally identical.

My approach to that is fairly simple, Login Controller that collaborate with an authentication service and an authorization service. The first to verify who the user is, the second to verify that the user even has the right to log in. I always use interfaces for those, so I would have IAuthorizationService and IAuthenticationService as the forth or fifth elements in my application.

Now, the reason for interfaces is actually not mocking, or anything of the like. If is simply because an interface allows me to create a strict separation between what is going on and how it works.

In order to complete the story, I may often need to write ActiveDirectoryAuthenticationService, but that is an implementation detail, I don't want to know about that. I want the interface to express just the required detailed for authentication, not to be involved with the details of actually handling the AD authentication.

In most projects I am going to have only one implementation of many of those types of interfaces, but the fact that I maintain this separation means that reading the code that makes use of those interfaces is far easier than it would have been otherwise. There is a wider line between the two collaborators, and far less chance of letting implementation semantics go through.

I was in place to try to extract those semantics out once or twice, and that is never pleasant or easy.

Wendy has a very good point here. Good practices, good design, are not there in order to facilitate some fad-of-the-day. The case she is giving is DI, SRP and SoC with regards to testing, and then taking the nuclear approach to testing, and deciding that since you can do just fake on the fly anything you need, you  can test without DI, SRP and SoC, therefor, you don't need them any more.

That is a problem.

Consider for a moment the guide lines for writing good C programs. Short methods, clear naming, guard clauses, etc. Those still holds today. In fact, pretty much all of the good design rules are not tied down to a technology or a language, and I have very rarely seen a case where it was beneficial to ignore design guidelines.

I am extremely suspicious of anything that asserts that "because you are using XYZ, then the following guidelines no longer applies." Dependency Injection is a good tool, which I can live without if other methods are provided, but ignoring basic guide lines such as the Single Responsibility Principal or Separation of Concerns is going to bite you in the end, each and every time.

Something really bothered me in JAOO. A couple of the presenters had a slide that showed something like this:

The Relational / OO Divide

• DBA not familiar with OO design
• Developer not familiar with SQL

I asked around, and apparently there is this assumption on the Java world that developers are usually only vaguely familiar with SQL. I am not sure if this is the case in practice or not, but that just sounds insane to me.

I live in the .NET world, and here I expect all developers to have a fairly good grasp of SQL and how it works. Not to the DBA level, I wouldn't really expect a developer to be able to fully analyze a query or optimize it based on index scan patterns for Oracle 11.g with patch XYZ.B, but I would expect that they would know SQL as well as they know their programming language of choice.

In fact, thinking about it, in most of my recent projects, a developer is expected to know at least the following languages:

This isn't really from choice, this is simply because those are the stuff that we use fairly often. It seems odd to assume that you would limit that. That would severely limit your ability to actually do useful work.