You don't say what the problem is. Is it performance? If so, on what tables?
Is it really the joins that are causing the problem? Or is it the stored procedures? You don't know (or at least, you don't say).
Best practice: figure out where your bottlenecks are first, before trying to solve a problem you haven't yet diagnosed.
On edit: I'm reminded of a time when on a job when we had performance problem. very slow stored procs, that could take minutes to complete. It turned out that these sps were doing utterly normal table updates, but using cursors. For stuff as simple as update t set c = c + 1 where id = n.
So to do an update, we were cursoring through a bunch of rows with a costly update cursor and doing an declare cursor for "select c from t where id = n" for update; then an open cursor and a read and an error check and a loop with a read and error check and then select c into @c; @c = c + 1; update t set c = @c where current of cursor; for each and every update.
Turned out the guy who wrote this didn't realize that we could just issue an update statement. And so he'd written dozens of these slow stored procs. We didn't even need to get rid of the stored procs (though that would have gained us some speed too, it would have changed our client); we just got rid of the cursors, replacing them with update statements. Performance problem gone.