Just because you're backend is an Oracle DB doesn't mean you have to use DataSets. NHibernate would work well as a replacement. Regardless, though, I don't see this as being a reason to not use MVVM. If you do it the "traditional WPF way" using the code
behind, you still do data binding to the DataSet. What difference does it make if the DataSet is exposed in the code behind or in a ViewModel?
Coding ViewModels is a little more complex than doing code behind. Especially in certain areas that everyone runs into when first starting out, like event handling, focus control and other similar concepts. However, there's solutions to these if you utilize
an MVVM framework, and learn to use the MVVM triad: commands, attached behaviors and services. Everyone has their own command infrastructure, but the best to look at if you don't know about this already is the DelegateCommand in Prism. Attached behaviors
were an old school pattern for leveraging attached dependency properties to modify a controls behavior by listening to events and modifying properties in response. This has recently been made more reusable and toolable with the advent of Blend Behaviors, though
I think the old school pattern is still something to leverage from time to time. Services are the final "silver bullet" and you just need a way to provide services to the ViewModel. Onyx (disclaimer: I'm the author, and it's still alpha quality code at best),
which you can find at http://wpfonyx.codeplex.com, provides ONE solution to that.
After a while, it's generally just as easy to code using MVVM is it is to code using "code behind spaghetti", while giving you all the benefits of decoupling (especially being able to test). You'll still run into things that take a while to devise the "best"
solution using one of the MVVM triad concepts, but really, that's true of any code you right. And like any such issue, you code it once, and then have a new tool in your belt for the next time.