Ayende @ Rahien

ulu commented on NHibernate and NDepend – skimming the surface

Fri, 14 Aug 2009 08:52:49 GMT

Thanks, now I see

Ayende Rahien commented on NHibernate and NDepend – skimming the surface

Fri, 14 Aug 2009 00:12:38 GMT

Ulu, It is actually quite common to have ISession decorated, see Active Record, Castle NHibernate Integration or Spring Integration. We give you an ISession interface, and you wrap it in another ISession that does additional things

ulu commented on NHibernate and NDepend – skimming the surface

Thu, 13 Aug 2009 20:27:43 GMT

@Dave Yes I know that in theory I should use abstractions and program to interface etc etc. I was just wondering about this particular case. Because each "should" has to have valid reasons behind it, and I was wondering whether these reasons apply here. "reduces your ability to substitute implementations" doesn't apply here, since we're not supposed to implement ISession yourself. "no scope to provide a mock instance for unit testing" -- I could say that you can always provide a manual stub or use a partial mock. However, as Ayende pointed out, mocking ISession is usually quite painful, and you better use SQLite for testing. "An interface represents the contract" true in general, but in this particular case the interface evolves over time, so the contract is.. violated? @Ayende "Use abstractions, not implementations" -- As I said, in general, I'm totally for abstractions. However, in all NH usage samples I've seen, If I replace ISession for Session, nothing seem to change. Don't take me wrong, I'm not questioning the quality of code here, just trying to learn by example. Thanks

Ayende Rahien commented on NHibernate and NDepend – skimming the surface

Wed, 12 Aug 2009 17:28:18 GMT

ISession and ISessionFactory are being _used_ outside of NHibernate. Use abstractions, not implementations. As for the I***Implementor, those are mostly needed because a lot of people want to wrap a session, and that gives them an easy way of doing that.

Dave Warry commented on NHibernate and NDepend – skimming the surface

Wed, 12 Aug 2009 15:37:19 GMT

@Ulu: An interface represents the contract (i.e. methods and properties) that is exposed, without saying anything about __how it is implemented. It's a fundamental (though often not taught, nor stressed enough if it is) principal that we should program to an interface, not an implementation ( ). Programming directly to a class couples your code to it, and reduces your ability to substitute implementations. If you had a Session object rather than an ISession you'd have no scope to provide a mock instance for unit testing, for instance.

ulu commented on NHibernate and NDepend – skimming the surface

Wed, 12 Aug 2009 11:37:15 GMT

Why do you use interfaces for ISession and ISessionFactory while they are not supposed to be implemented outside NH? Another question is, you do have ISessionImplementor and ISessionFactoryImplementor. And I always thought that interface and implementation are opposites. So, why these names? Just curious..

Ayende Rahien commented on NHibernate and NDepend – skimming the surface

Mon, 27 Jul 2009 16:39:38 GMT

> Heaven forbid someone would want to actually plug in their own SessionFactory Yes, heaven forbid. Those are not parts that you are supposed to mess about with, not from outside.

Mike Brown commented on NHibernate and NDepend – skimming the surface

Mon, 27 Jul 2009 16:29:49 GMT

"•SessionFactoryImpl have cyclic relationship with SessionImpl and StatelessSessionImpl. Again, we don’t consider this a problem, those classes are tied together by the nature of their existence. SessionFactoryImpl have to be able to create the sessions, and they need to access it to be able to touch everything that isn’t session scoped. " Wait you're saying a Factory having a cyclic relationship with the object it creates is not problematic? I guess the rules only apply when you're talking about other people's code not your own. So the argument is that removing the cycles introduces "needless" abstractions. Heaven forbid someone would want to actually plug in their own SessionFactory without recompiling all of NH. Get real. It's okay to say "We only had so much time and effort" but to defend sloppy code as not problematic because we know how it works or doing so would only create unecessary abstractions that will "make it more difficult to understand"? What's difficult to understand about a Session taking a dependency on SessionFactoryBase or ISessionFactory? I've seen BS before, but with all the preaching that you guys do about making code more maintainable and the importance of DIP, it's hilarious that you actually think that this doesn't go against every principle you tout. It's like telling your kids don't do drugs but when they catch you smoking weed in the basement saying "it's okay I know what I'm doing".

Patrick Smacchia commented on NHibernate and NDepend – skimming the surface

Sun, 26 Jul 2009 18:34:35 GMT

>"The practical effect of those pressures is that great teams make structure changes as they touch code to work on new features or fix bugs" Indeed, I misunderstood. But still we disagree on what is the technical debt. >> "It needs to be looked at NOW." is an entirely academic statement. > And one more tack at academic.... >See now your just being deliberately unfair. It would be nice that no-one around use the term academic then, because despite your explanations the way you are using it really sounds to me like: "It needs to be looked at NOW." is an entirely {non-realistic, non-real-world, non-practical, non-pragmatic} statement. 'theoretical' is much suited then, and 'theoretical' is not 'academic'.

Jon Palmer commented on NHibernate and NDepend – skimming the surface

Sun, 26 Jul 2009 18:20:38 GMT

Patrick, you continue to misread or misinterpret what people are saying in their comments. You said: "In essence you are claiming that in the real world, 'technical debt' cannot be re-paid because there is always something more urgent to do." but that is not the essence of my argument at all. Please read my comment more carefully and you'll see what I said was: "The practical effect of those pressures is that great teams make structure changes as they touch code to work on new features or fix bugs" So I'm in total agreement with the Fowler quote. The key part of Fowler's quote is "You have a piece of functionality to add" he is NOT talking about making changes for the sake of change he is talking about limiting or eliminating technical debt when you are in there already adding functionality. We are in total agreement that we should avoid incurring adding technical debt as we add of fix features. However, we disagree on the value of focusing on any given metric in isolation or that simply attacking the problem described by that metric is in itself a practical approach to building.software. >> "It needs to be looked at NOW." is an entirely academic statement. > And one more tack at academic. Did you guys really feel that the job of the academic world is focused on disturbing developers from getting their job done? See now your just being deliberately unfair. I never said anything of the sort about the role of academics in advancing software engineering. However, I will say that sticking to 'academic' or 'theoretical' arguments without practical real-world consideration is a mistake and potential damaging idea to up and coming software engineers. Great software engineers (and they are very different from great coders) and great development teams understand that building software involves a continuous set of trade offs. You have to trade off long term vs short term goals, I need it now vs I might need it later, abstract purity of design vs technical debt etc. etc. You have to understand technical debt and you must actively make the trade off. However, that doesn't always mean that fixing technical debt always wins the trade off. Arguing (and I paraphrase) that "Cyclic dependency is bad and must be fixed NOW" does nothing to educate engineers about how and why to make those trade offs in the real world practical situations that they face every day.

Patrick Smacchia commented on NHibernate and NDepend – skimming the surface

Sun, 26 Jul 2009 16:05:57 GMT

oh and I forgot: > "It needs to be looked at NOW." is an entirely academic statement. And one more tack at academic. Did you guys really feel that the job of the academic world is focused on disturbing developers from getting their job done? Aren't most of successful concepts that we use today invented by academic? (object, relational DB, functional, parametric polymorphism, compilers, DbC...) How can you both use all the goodness coming from academic and permanently present academic as a world where people doesn't know what is it to code in the real-world?

Patrick Smacchia commented on NHibernate and NDepend – skimming the surface

Sun, 26 Jul 2009 15:51:06 GMT

I have nothing to add that Dinesh already wrote except one comment on this: >Its very very rare that you have such a wealth of resources that you have the luxury of making changes that drive nothing more than code structure. In essence you are claiming that in the real world, 'technical debt' cannot be re-paid because there is always something more urgent to do. Here is what Martin Fowler wrote on technical debt: "You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place." (...) "The Technical Debt metaphor explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments."

Sandor Davidhazi commented on NHibernate and NDepend – skimming the surface

Sun, 26 Jul 2009 14:07:29 GMT

@Patrick I agree with Jon. > "I can't believe you guys are the same guys who keep on arguing about all the benefits of SOLID principles (which includes Low-Coupling as a main effect) and yet argue that those principles aren't needed in nHibernate ?" This happens when principles are applied in practice. They become intelligently applied guides instead of unbreakable laws. > "You need to understand Highly coupled classes aren't "false positives". It needs to be looked at NOW." By your academic standards, yes, NH classes are highly coupled. By practical real-world standards concerning day-to-day work, they are not spaghetti or brittle to change, their level of coupling is just right. It's not a problem that should take valuable time. Do you value scientific approach over NH down-to-earth developers' opinion? (I feel I can't add any more to the conversation, so I'll probably just leave it at this.)

Jon Palmer commented on NHibernate and NDepend – skimming the surface

Sun, 26 Jul 2009 13:24:55 GMT

>You need to understand Highly coupled classes aren't "false positives". It needs to be looked at NOW. This is an attitude that is echoed in a lot of the post around this subject and its sadly misguided. In a perfect world we would have infinite resources and be able to fix all problems (bugs, new features, code structure). However that is never true in the real world. In the real world resources are finite. So the real questions we face are things like: "given 4 hours to work on NHibernate today should I add feature A, fix bug B or refactor classes C and D to reduce cyclic dependencies". Its very very rare that you have such a wealth of resources that you have the luxury of making changes that drive nothing more than code structure. There is always a much greater presure for features and bug fixes. The practical effect of those pressures is that great teams make structure changes as they touch code to work on new features or fix bugs. That deliver incremental code improvement along with tangible external improvements to the product. IMO the NHibernate team has done a superb job of maintaining that balance. "It needs to be looked at NOW." is an entirely academic statement. Any development manager that went to their CEO and proposed no new releases or features for 6 months so they could focus on removing all cyclic dependencies would be looking for a new job pretty fast.

Dinesh Gajjar commented on NHibernate and NDepend – skimming the surface

Sun, 26 Jul 2009 12:06:38 GMT

@Sandor, So you are saying Low-Coupling is not important and require some kind of proofs for proving it's importance ? I can't believe you guys are the same guys who keep on arguing about all the benefits of SOLID principles (which includes Low-Coupling as a main effect) and yet argue that those principles aren't needed in nHibernate ? Proves more concretely that ALT.NET is just about hypocrisy. Everyone should follow(in particular Microsoft!) your idea of software development. But when it's convenient you can change or break the principles. nHibernate is great product, but that doesn't mean it can't be improved. The fact that Ayende is doing posts on this means it's important and is being looked at. That's good enough to move the product forward. You need to understand Highly coupled classes aren't "false positives". It needs to be looked at NOW.

Sandor Davidhazi commented on NHibernate and NDepend – skimming the surface

Sun, 26 Jul 2009 12:01:06 GMT

And to clarify my argument, the testimonies on your site are about all the features of NDepend, and I don't contradict that NDepend has very useful features. It's about you mainly basing your arguments on the ADP.

Sandor Davidhazi commented on NHibernate and NDepend – skimming the surface

Sun, 26 Jul 2009 11:39:14 GMT

> "Who on earth can have an understanding of 580 classes entangled?" You seem to be hell bent on the idea that it is almost impossible to maintain the NH code base. You seem to neglect the fact explained by Ayende that it's architecture was designed in a way where some inter-dependency is inherent to it, and it's still logical, and understandable, it still makes sense, and he can explain how each component functions and how it could be changed or extended any day. The NH codebase has neither high nor low component coupling. It has the _right_ amount of coupling. You have to accept and learn to live with the fact that there is a margin of error to the level of inter-dependency, and IRL you can't measure it based on scientific principles invented for a perfect world, and so the measured 75% of inter-dependency translates to an indicator that may or may not give true information on how hard it is for a coder to maintain a codebase in his day-to-day work. > "My big point is that the Acyclic Dependency Principles (ADP) is extremely efficient in the real-world and is easy to apply." You warned Ayende about your concerns, he drew his conclusions and answered you in the above post. IMHO now it's your time to reconsider your seemingly unchangeable ideas and learn to accept the fact, that measuring by the academic ADP can not be considered a hard fact when it comes to determining the maintainability of a code base in real-world applications. It is an indicator, yes, but it may have given false positives in these cases, as explained by the concerned developers themselves.

Patrick Smacchia commented on NHibernate and NDepend – skimming the surface

Sun, 26 Jul 2009 09:33:30 GMT

>You created a software that analizes software based on scientific principles. ...scientific principles that I didn't invent. These scientific principles comes from 2 decades of research (academic+industrial). See the references above. >anything but your principles backed up in an academic level One more time academic is negatively presented :o/ >ndepend's redesign was justified by itself Yes, I am enthusiast on working on a code base extremely low-coupled, completely componentized and layered, where every maintenance task is immediate. My big point is that the Acyclic Dependency Principles (ADP) is extremely efficient in the real-world and is easy to apply. [codebetter.com/.../NDependTypesDSM.jpg](http://codebetter.com/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/patricksmacchia.NHibernate2_5F00_1/NDependTypesDSM.jpg) Hopefully I defend (and apply) much more principles than just the ADP, immutability, high test coverage + DbC, small iterations, reversibility... >Can you justify the redesign of nh besides anything but your principles backed up in an academic level presented in pretty matrices? NH coders are big names. My unique concern comes when they justify 580 classes inter-dependent. Because they are big names, many developers can find here a justification to not care about their own hundreds of inter-dependent classes. >You have to stop thinking binary when thinking about code inter-dependency. >Ndepend knows only two colors >Please realize that there are levels of inter-dependence. As said above, spaghetti are here when a 'significant' portion of the types indirect dependency matrix is black. The adjective 'Significant' is not binary. But certainly 40% or more of inter-dependent classes is IMHO more than significant. >You have to realize that binary ndepend analysis results (black-square-no black square) can't indicate directly how hard it really is to understand, maintain or extend any code base Who on earth can have an understanding of 580 classes entangled? >Please stop bugging coders of different frameworks Some developers are open to free advices. For example Craig Sutherland leading CruiseControl decided recently to allocate resources to achieve low-coupling in CC.NET. [codebetter.com/.../...e-control-net-code-base.aspx](http://codebetter.com/blogs/patricksmacchia/archive/2009/04/23/ndepend-and-the-quality-of-the-cruise-control-net-code-base.aspx) >saying they don't practice what they preach, because they write inter-dependent code. Indeed there is a case of a big name where: -he spend his time preaching for low-coupling -he wrote a code where 75% of its classes are entangled -he insulted me on twitter What am I supposed to do in such case? >how ndepend brought business value to companies I usually avoid talking business in a purely technical discussion, especially a polemical discussion. NDepend has thousands of pro users world-wide. If they bought the product they certainly find a benefit in it but I refuse speaking in their names. So here are some more tangible facts: [codebetter.com/.../...-code-in-the-real-world.aspx](http://codebetter.com/blogs/patricksmacchia/archive/2008/09/23/getting-rid-of-spaghetti-code-in-the-real-world.aspx) + [http://www.ndepend.com/Testimonials.aspx](http://www.ndepend.com/Testimonials.aspx) + The last one in date: Quote from Jeff Brown above: The last time I threw NDepend at Gallio (which is about the size of NHibernate, iirc) I discovered interesting things about the components and ended up rearranging the conceptual layers and pushing the abstraction boundaries around a bit. It took some time to figure out the issues that the tool was really hinting at but I feel that the refactoring that came out of the process has been extremely worthwhile. PS: Guys, all these discussions are as interesting as exhausting. If some-one has something to add please make sure it hasn't been debated above, thanks!

Sandor Davidhazi commented on NHibernate and NDepend – skimming the surface

Sat, 25 Jul 2009 19:02:12 GMT

@Patrick You created a software that analizes software based on scientific principles. In practice business requirements drive resource allocation, and leaders have to consider ROI in every allocated man-hour. You had the resources (developer hours) to stick to your principles while redesigning ndepend, because ndepend's redesign was justified by itself (the proof is the product). Notice the cyclic dependency? ;) Can you justify the redesign of nh besides anything but your principles backed up in an academic level presented in pretty matrices? You have to stop thinking binary when thinking about code inter-dependency. There are many shades. Some of them are: not inter-dependent at all, acceptable inter-dependency, inter-dependent, very inter-dependent, entangled spaghetti code. Ndepend knows only two colors (literally): not inter-dependent at all and spaghetti code. You only see code through the eyes of ndpend and say: stick to these principle fully, or be fking doomed with your spaghetti hell. You have to realize that binary ndepend analysis results (black-square-no black square) can't indicate directly how hard it really is to understand, maintain or extend any code base, and how much _business_ value it would give to redesign the code just to make black squares disappear. Please stop bugging coders of different frameworks, saying they don't practice what they preach, because they write inter-dependent code. Please realize that there are levels of inter-dependence. Finally, start putting practical, real-world facts on the table: hard facts that show a trend on how ndepend brought business value to companies. 9-10 projects which benefited from making black squares disappear in ndepend, and also _how much they benefited approximately_ (not just an ego-stroking "we feel better about our code") will be a great start.

Patrick Smacchia commented on NHibernate and NDepend – skimming the surface

Sat, 25 Jul 2009 12:57:30 GMT

Fabio, when quoting my post it would have been appropriate to quote as well the caution I underlined in bold in the post: "Notice that I don't claim that this indicator is resulting from a scientific approach (it is not the case). I just found the result interesting enough to be shared publicly. Just take these numbers as-is." In this post I just share some interesting insights that all other ISV keep private. I wish more ISV would share such info, it would be very interesting. Btw, I wish the NH project could also share this info. >but absolutely not arbitrary conclusion as "NH is spaghetti code" This is not arbitrary. What is the definition of spaghetti code if it is not: A significant portion of implementations are statically inter-dependent. And in NH, the demonstration that a significant portion (around 40% of the 1456 classes) of implementations are statically inter-dependent is made obvious by this dependency matrix. [codebetter.com/.../TypesDSM.jpg](http://codebetter.com/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/patricksmacchia.NHibernate2_5F00_1/TypesDSM.jpg) Realize that 40% of your classes depends on 40% of your code base. Something like 580 classes involved in a giant cyclic graph! From any of these 580 classes you can find a static path to the 579 others and vice-versa! The small cycles exhibited by Ayende is just an epsilon of the problem. Maybe you can justify things epsilon by epsilon. But at the end of the day hundreds of classes are still inter-dependent! This is not my fault, this is not showing disrespect to shed light on this, it is tangible facts. Why do you stay on your stance when facing such an obvious problem? Why being so defensive? Why not changing your mind and see the results presented in the analysis as something you can benefit from to reduce overall NH coupling?

Frans Bouma commented on NHibernate and NDepend – skimming the surface

Sat, 25 Jul 2009 12:56:40 GMT

@Fabio: why do you take offence of things which are simply digged up from the code which is structured according to something you have no control over? (hibernate) It has already been discussed that nhibernate is structured the way it is because hibernate is structured the same thing. Whether hibernate thus has to be restructured is something we all can do little about. IMHO you shouldn't take these things so personal. I mean, for every time someone cries out that POCO is the way to go and my own o/r mapper therefore sucks as it promotes anti-pattern XYZ etc., should I take it personal? Take my advice: don't take it personal, look into why these questions are asked, what valuable lesson can be learned and if so: if you want to fix it or not or live by it. You know why the code is structured the way it is and you think it's OK. Advice is given to change it, you then should look into that and take a conclusion: we don't change it because for reason ABC, or yes we should change it because of reason XYZ. That not only learns you to live with criticism better but also you might get valuable advice from it once in a while. It helped me to deal with 'code generation sucks' and 'not using poco is bad' kind of criticism as I know why I use code generation and not poco.

Fabio Maulo commented on NHibernate and NDepend – skimming the surface

Sat, 25 Jul 2009 11:42:55 GMT

You can see an analysis of information to give some conclusion about a situation. What I'm not agree are that conclusion "spaghetti", "impossible to maintain" and so on... Do you want see another arbitrary conclusion from the same guy ? [codebetter.com/.../...re-for-software-quality.aspx](http://codebetter.com/blogs/patricksmacchia/archive/2009/07/05/where-do-developers-care-for-software-quality.aspx) IMO when Patrick analyse a software he should write something about how he would solve what he define a problem in that software. Instead Patrick write his arbitrary conclusion and nothing more. I can respect the guy when he respect me and, over all, our work. I can accept constructive critics but absolutely not arbitrary conclusion as "NH is spaghetti code". Btw my congratulation to Patrick for his commercial strategy... every time it is working very well.

Jeff Brown commented on NHibernate and NDepend – skimming the surface

Sat, 25 Jul 2009 08:56:17 GMT

In my experience a cyclic dependency between two components is often a sign that there is some other important concept at work that can be factored out orthogonally to both. Alternately one dependency can be inverted to eliminate the cycle and reduce coupling. This is not true in all cases certainly but I do find the study of these cycles to be occasionally very enlightening (and occasionally not so much!) For example, IType may not actually need everything that ISessionImplementor provides or vice-versa. There could be some more general abstraction lurking in the shadows waiting to be discovered here. Maybe all IType really needs is some kind of factory that ISessionImplementor can provide. I can't tell you whether it is worth pursuing but often when I find and adopt such an abstraction the tests become much simpler and require fewer mocks to arrange. The last time I threw NDepend at Gallio (which is about the size of NHibernate, iirc) I discovered interesting things about the components and ended up rearranging the conceptual layers and pushing the abstraction boundaries around a bit. It took some time to figure out the issues that the tool was really hinting at but I feel that the refactoring that came out of the process has been extremely worthwhile.

Richard Lopes commented on NHibernate and NDepend – skimming the surface

Sat, 25 Jul 2009 06:35:17 GMT

I am very disappointed by Jeremy D. Miller and his twitts. He has been preaching a lot of good practises that can be enforced and verified by a tool like NDepend. There is no best way to make sure you are following these good practises. The big problem with twitts is that you just have the space for a statement not for elaboration. However Patrick work and NDepend are highly regarded and the metrics used are very relevant indeed. There is no doubt in my mind that if your code, library or application does well in the tool, it will be low-coupled, testable and maintenable. It does help make clear where architecture problems are. So far, I don't see anything close from a tool like NDepend on the market. The other option is human judgement and opinions, and this is never rational or a scientific approach. There is habits, difference of understanding, personal preferences... It is also a good tool also to discover if "gurus" follow what they preach and the recent uproar is a testament to that.

Patrick Smacchia commented on NHibernate and NDepend – skimming the surface

Fri, 24 Jul 2009 15:43:04 GMT

> It will give you Low-Coupling. > No, in my judgement would create artificial abstraction that would only make things harder to understand. On this we fundamentally disagree then. The Acyclic Dependency Principle has an awesome power. Indeed, this principle guides developers on where precisely abstractions must be created to reduce coupling between implementations. For you such abstraction is artificial. For me it represents the corner-stone of low-coupling. And I can affirm without any doubt that reducing coupling between implementations doesn't make things harder to understand.

Ayende Rahien commented on NHibernate and NDepend – skimming the surface

Fri, 24 Jul 2009 14:45:12 GMT

> It will give you Low-Coupling. No, in my judgement would create artificial abstraction that would only make things harder to understand.

DaRage commented on NHibernate and NDepend – skimming the surface

Fri, 24 Jul 2009 14:42:38 GMT

> too much time waste... too much... I think you're wrong. I don't think spending 2 days or 3 days or even a week after such a major release to analyse and examine the fundamentals as bad, but very useful. I think you should do it as a team to gain insight for the next release and bring everybody in team to same page when it comes to architecture. And I think you should also thank Patrick for doing the analysis for you.

Phil commented on NHibernate and NDepend – skimming the surface

Fri, 24 Jul 2009 14:36:30 GMT

NDepend has gotten enough free advertising out of this now. Spending energy on this is taking away from the excitement of a big release that we all benefit from. The level of extensibility of NHibernate speaks for itself. If the coupling were as bad as Patrick says that it is we would not be able to extend and write our own implementations for NHibernate interfaces as easily as we can.

Patrick Smacchia commented on NHibernate and NDepend – skimming the surface

Fri, 24 Jul 2009 11:53:37 GMT

a) in many cases, it is not actually possible. See IType <->ISessionImplementor And again type inter-coupling is not a bad things when types belongs to the same components. Having IType <->ISessionImplementor is just a good indication that these interfaces conceptually belong to the same component.

Yann Schwartz commented on NHibernate and NDepend – skimming the surface

Fri, 24 Jul 2009 11:37:43 GMT

Fabio "NH2.1.0GA ~1000 downloads in 6 days, NH2.0.1 +70000 downloads in 10 months... many professionals like our spaghetti." Yeah, right. Let's go along this path. How many people use strongly-typed datasets? Many professionals like strongly typed datasets. So they must be GOOD. You seem to take issue personnaly each time someone dares to say something about NH (an outstanding framework, BTW) which is not pure ecstatic raving. So does Jeremy Miller. I can understand that, since some of the most vocal alt.net proponents are known for their well-balanced and meek comments on other people's work, and it's only fair you should be entitled to be treated the same gentle, reverent way. Way to go Jeremy, way to go Fabio. I can understand how outrageous it can be to have someone utter non-insulting comments about your framework. How dare they? BTW, Oren's replies are well thought-out, even if it sounds like Patrick and him are somehow talking about different things.