<personal opinion>
It's a nice design, and I appreciate the time you have spent doing this. However, I usually think that modules like this one can be more dangerous than helpful, since they don't add anything but they hide functionality that a beginner could eventually get acquainted with, had it been available.
</personal opinion>

In any real world DBI application, I am using more than one $sth, so that I can have multiple queries with the same connection. Even without talking about DBI's advanced features, I would say that this module is just too simple for normally demanding database applications.

As an example, let's have a look at a classic case of customer / order situation. We have to query for the customer ID, and for each ID we want to perform something on the related orders.

Note: There are things in this situation that can be done directly with one SQL query, and others that require separate ones. For example, if we want to display all the data for each customer, and then ask for their orders, it would be disastrously inefficient to join customers and orders.

# untested but realistic
my $dbh = DBI->connect("...",{RaiseError => 1} ) or die "can't\n";

my $cust_sth = $dbh->prepare(
    qq{SELECT cust_ID, cust_name from customer});

$cust_sth->execute();

while (my $cust = $cust_sth->fetchrow_hashref()) {
   my $orders_sth = $dbh->prepare(
        qq{select * from orders where cust_ID = ? });
   # do something smart with customer name

   $order_sth->execute($cust->{cust_ID});

   while (my $order = $orders_sth->fetchrow_hashref()) {
       # do something even smarter with the orders data
   }
}
[download]

With DBIx::Simple, I should either copy the result of the first query to an array, and suffer the copy delay, or create two objects (and bear in mind that in a real application I need to use more than that), thus having two connections and their relative overhead.

<personal opinion>
Anyway, everyone is free to see things from a different angle. I wouldn't either use nor recommend such a module for a real project. As for teaching, I'd rather go through the more rewarding details of the DBI. It's something the students needs to handle if they want to be more than second-rate database programmers.
It's like learning regular expressions. You can get a wrapper that builds a regex from some procedural instructions, but you won't ever learn them if you don't manage to overcome the initial shock and be able to read and understand the "line noise".
</personal opinion>

update
Interesting database applications are too complex to quote some meaningful example and discussing about their implementation. However, my abstract consideration on the issue is that DBI is already a wrapper over the DBD driver, which is another wrapper over the database API. Knowing this, I try to avoid any further layer.
Moreover, DBI has still room for more features rather than a need for reducing them.

 _  _ _  _  
(_|| | |(_|><
 _|
[download]

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.