You'll find it much easier if you think in terms of a model that the UI consumes. You'll want to do that anyway if you were to ever plan on sharing your business logic with other UIs, like Silverlight, MVC or (gasp) WebForms. That in itself takes some planning and forethought but it is possible. Your model knows nothing about UI elements, and your XAML code just binds to these properties on your model. Don't be afraid of having some code in your codebehind. I'm not in the camp that believes codebehind is evil, but if you're writing code that deals with business logic in codebehind you need to evaluate how that code goes into the model, and move it there. (Jumped into XAML a year ago and I'm never looking back.)

It reminds me of the difference between the .net runtime of Silverlight and regular .net- it has less features, but any roadblocks you encounter that are caused by a missing feature can always be worked around. On a side note, I have a client who wants their invoicing system rewritten. The whole thing is a 10 screen nightmare built in excel vba, using hidden worksheets to store data. Ugh.

Saying Java is great because it works with all platforms is like saying anal sex is great because it works with all genders.