On RYO vs. NIH
Bil Simser has stepped into the complexity debate with this post.
This is actually on the end of Bil's post, but it deserve a special mention:
In that, I haven't done justice to the P&P team. Introducing Agile methodologies and best practices is something that I am very passionate about, and I failed to give them their due credit about their efforts in this direction.
After you have built one application like this, you can extract the relevant parts into a "framework", although I am not sure that I like the term. The main difference being, again, that this is something that is driven by a developer seeking to make life eaiser, not by BDUF.
The end result is often a purpose fit framework that is very easy to work with, and doesn't require years of study.
Not really, the basics are deceptively simple, but then you are going to hit a lot of issues with dependencies cycles, life time issues, etc.
Not really, I would tend to use best-of-breed stuff that I would have available, it would cut the stuff that I would need to build by 60% at least. But I would not build the EntLib by any means, I may have components that have similar functionality, but in general, it would be a set of services, not a framework. Jeff Brown had a good post about the difference between the two.
The first part and last parts of the sentence conflict each other, fairly badly. If they are so complex, I would get much better ROI than rolling my own, or (more likely) reusing stuff already built that isn't so complex.
Don't you think that this is an issue when you can't get the basic concepts of a framework in an hour without drowning in the details? Apples to oranges, but I can show a MonoRail application that has nothing but the basics, and talk about that and the concepts underlying that. If the technology is obstructing the end goal (creating maintianable applications), how is it useful?
Well, considerring that Frankenstein was a very smart doctor, probably a good one. I think you meant something else, and I am getting tired of answerring that statement, frankly. Using several components together is neither cobbling nor frankenseining nor hobbling a solution, it is using the best attributes of each to achieve a cohesive whole. The end result of a highly componentized architecture is... good design.
This is were all the trouble start. I am explicitly not saying that the P&P guys did a bad job, I am saying that I don't believe that the direction they are pushing is the right one.
Bitchy: Feel free to try to deploy P&P's DAAB without Microsoft.Practices.EnterpriseLibrary.Common, when you are successful, then you can complain that NH has a dependecies.
Seriously, NHibernate.dll has dependencies on several assemblies. And it follows separation of assemblies, so if, for instance, you don't need the 2nd level cache, you don't need the MemCached assemblies deployed.
You get that with everything that you use, if it bothers you, use ILMerge to make this a single DLL, and then forget about it. Disk space is cheap, and it is really not an issue. About the previous point as well, you can merge log4net into NHibernate if you so like, and get rid of the extra dependency.
I seriously doubt it. A good collection of tools would enable you to write clean, intent expressive code. I don't think that you would end up with more code, if anything, the lack of designer generated code would reduce the amount of code that you would have to deal with.
Comments
On NHibernate’s log4net dependency: I really think this dependency ought to be removed. Logging frameworks varies from application to application, and the decision of which one to use shouldn’t be made by any single component such as NH. Log4net’s strong name screw-up between 1.2.9 and 1.2.10 is another reason (you need to recompile NH if you have other dependencies that cannot change – not a big task, but still).
Has this been discussed by the NH team? You’re all aware of it, I’m sure. Castle has done it right, of course. Spring.NET introduced a simple lightweight logging abstraction framework to get rid of its hard-coded log4net dependency (http://netcommon.sourceforge.net/). Perhaps it could be used, especially since it wouldn’t introduce any other new dependencies? Is there any interest in doing so?
Frankly, I am against that.
The screw-up was a big issue, I agree, but I don't see the point of abstraction for the point of abstraction, and what it wrong with another Dll.
I don't think that we are likely to see the same issue as the PK screw up, so I don't really mind the dependencies. The problem in saying that you can't take hard dependencies is that pretty soon you start to get really lost. What happen if you want to use NHibernate with Spring, NHibernate is using some Castle stuff, is this fine? If not, how are you going to replace that,etc.
Spring vs. Castle is quite a bit different, I think. (Spring.NET uses Castle's DynamicProxy, doesn’t it? Anyway, that's not the point.) I feel you're much less likely to run into such issues, and if you do, you need to handle it differently, as you imply.
Logging, however, is a necessity of pretty much any application, and you want to be able to choose which one to use (and log4net isn't the best option out there). It might even not be your decision. And who wants to use more than one framework? (And for writing an appender to log to another framework... I'd rather not.)
I feel I shouldn't be forced to use log4net simply because I want to use NHibernate - an O/R-mapper. Those are completely different concerns. After all, isn't that why both Castle and Spring has abstracted logging?
I totally agree that you shouldn't make unnecessary abstractions, but this isn’t one of them. Sure, you shouldn’t abstract the logging in your own application code, but reusable components should, IMHO.
I'm not up with the lingo - I was wondering, what's NIH?
Chris
NIH = Not Invented Here ?
I tried to post on that blog but I got some Community Server database unavailable error with instructions on how to set a connection string up.
lol
but, I wanted to say:
Here is the quote from the Web Client P&P Factory:
"The software factory uses the Enterprise Library for a variety of features, including exception management, logging, data access, and authorization."
Let me ask Bill and P&P:
I have a DDD in place that uses NHibernate and a IRepository/DAO approach
I use Windsor for some of my DI needs
I have a MVP webform solution in place.
Can I plug in my approach into this 'factory'. Must I use their DAAB?
Must I use this cobble of EntLib 'features'? ie. I want to use log4net, but can I with this 'logging' feature?
It seems P&P supporters want to be critical of my approach without giving me a way to plug in my components into their architecture. It appears I must either use their system or nothing.
I don't understand this - if I have a success system that uses NHibernate or Windsor - why can't P&P create a framework that let's me use the components I use to solve business problems with?
I see effort on the OSS side to provide a way to use components. ie. Castle's 'Facilities'. Plug in a facility.
This is my issue right now - I want choice in my design. If P&P can give me that choice, I'll go use it. But if they want to bully me into a solution, where I must use a 'objectbuilder' instead of Windsor, or where I must write stored procs with 'DAAB' rather than my DAO/NHibernate solution then what is the value for me?
I could be missing the point here, but I see P&P as a hodgepodge of their own components, trying to glue them all together but not allowing anyone else's components to plug into their large bulky architecture (although they have pretty pictures on the website). I know the post said something about mastering it after a YEAR!. Whew. A year is a long time, I don't know what will be here a year from now :)
There is absolutely nothing wrong with Frankenstein-ing or cobbling together a solution. It does not mean you are re-inventing the wheel or being in-efficient. It's more like buying a custom computer, or a custom house or a custom car. It's about you getting exactly what you want in both form and function. At the end of the day, to use the car example, both the standard car and the custom car will get you from point A to point B, but the trip could be completely different. Both types of cars have their strengths and weaknesses, but at least with the custom car, you got to choose both.
I'm not saying that everyone should only roll their own frameworks... Or only cobble together multiple frameworks... Or only use a single monolithic framework... At the end of the day, a good developer, a smart developer, will evaluate all of those options, and then some, and will choose the right solution for the task at hand. A good developer will not be biased in their decision making just because they have used a particular solution with success in the past. A good developer always re-evaluations the situation.
100% in agreement ... was going to write a reply to Bill myself ... but I couldn't add much beyond what you wrote.
"If you consider systems as services and the ability to plug in any service you need, then you get the best of both worlds and I don't consider any of this cobbling solutions together."
Good, because that is how I feel as well. And honestly, that is what I think we should strive for.
Choice is good.
Thanks for your followup.