+972 52-548-6969
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.
