1) For saving (inserting/updating/deleting): Because a class can define its own persistence strategy (by using its own IClassPersister implementation and using the attribute "persister" in the mapping file), it is possible to redirect the insert/update/delete operations to call stored procedures, instead of generating dynamic SQL.

In this case, the basic strategy would be:

- Inherit from the appropriate IClassPersister class (AbstractEntityPersister, EntitiyPersister or NormalizedEntityPersister)

- Override the corresponding Generate[Insert | Update | Delete]Strings method, to build a stored procedure call, instead of a DML SQL string.

- Override the corresponding action method(s) (Insert(), Delete(), Update()).

2) For loading data: I guess that if you are using a RDMBS that supports user-defined functions that return result sets, the best strategy is to:

- Move the logic from the stored procedure to a user-defined function
- Create a view that returns the result set from the user-defined function
- Use the columns of the view in the Xml mapping file
- Of course, to persist such class, you will need to define you own IClassPersister, as explained in the item 1.