Well, if you're planning on using similar interfaces, where they all have something akin to an "update_screen" method, etc., then your idea--of a DBI-like interface to implementation modules--sounds like an interesting one.

The problem with that is that if you move into other interfaces, they don't necessarily have the same paradigms as your current interfaces--so you end up grafting functionality meant for one interface onto a completely different, and non-fitting, interface. The key, I guess, is to be as abstract as possible.

I'll tell you, though, how I've done similar things in the past. Rather than objectify my interfaces, I've objectified the backend--I've created an API that lets me manipulate the objects that my *interfaces* will be manipulating. Then across all of my interfaces I have a standardized way of updating, modifying, adding, and removing data (or whatever it is that you're doing).

The interfaces, then--since they really don't have much in common, in my case--exist essentially as UI wrappers around my API. And they don't need--and shoudn't--be sharing functionality, because there's none to share; a forms-based web interface, in my mind, doesn't share much functionality with a command-line interface, for example.

Just to give you some ideas.

By the way, there are really no problems using require instead of use. Just make sure you wrap it in an eval in case it blows up (since it'll be a run-time error). Just remember that using require won't call import for you, whereas use will. So if you're exporting, that's something to be aware of.