[ebiester]

In my case, I'm speaking of a reaction to Spring and Struts. I personally use Grails on my recent projects, which is as close to batteries-included as it gets, but I occasionally have problems with square peg round hole problems, and fighting against a framework is more painful than a library.

The problem with the framework is that we run into a steep hill when we must diverge off the path. A good framework gives a great story. Unit tests, integration tests, consistent layers, convenient and powerful ways to access the database without writing a giant SQL generator (if x return "and b.id = c.id" else return "b.name = "%" + name + "%")...

But then, you hit the use case that the framework didn't consider. And suddenly, you either need to extend the framework (never pleasant) or go outside the framework for one portion, which means building all of the tools from the ground up.

Or, more often, ignore testing, hack in the best way you know how, and hope nothing breaks.

The library approach means that you have to build the integration pieces yourself. This is painful, but it means that when you reach a new use case, it isn't as large a jump to keep going.

Each has tradeoffs. There are times when each is superior. Someone like Bob Martin would suggest that you build your system independent of frameworks and treat the web as a client/compatibility layer, and that you build your system of small composable parts so that the framework/library question is a minor one. (This has its own tradeoff with an abhorrent amount of plumbing code that comes along.)

It all comes back to the problem at hand and how we judge the tradeoffs, like most engineering problems.

[mattgreenrocks]

Do you know of any shops that use Uncle Bob's approach (besides 8th Light, of course)? I don't; I wish I did. I agree that isn't something you'd use every time, but I feel there isn't a whole lot of data out there when people have used it. All I see online are devs whining about the extra work.

I don't know what it is about the web, but it's as if we decided all of software architecture didn't mean anything and threw it out. My theory: it's harder to feel coupling in a dynamic language, thus it's just an academic concern!

[ebiester]

I have plans to try it in a side project. I too am skeptical about the rewards of setting up a CRUD system like that.

It isn't that we've decided that software architecture meant nothing; rather, we settled on one architecture that is Good Enough. The View/Controller/Domain paradigm of Rails works for many projects.

[mattgreenrocks]

It won't be great for CRUD. It's really meant for applications that have a bunch of business logic to them...you know, the interesting apps.

Aside: "good enough" seems to summarize the web as a whole. This is both discouraging and a fact of life.

[ebiester]

You can still have an interesting business logic system that is CRUD at its core. A case management system, as an example, is CRUD at its basis but filled with business logic.