c# - Why use private methods in WPF MVVM? -

i took on development of relatively mature wpf mvvm project didn't have lot of unit tests. once understood of code doing thought it'd idea write more.

now, don't have experience of either mvvm or wpf seems obvious given relatively limited, property-based binding between ui , code, lot of logic can locked away behind private methods. that's i'd have done, , that's predecessor had done.

unit testing private methods bit of pain (i know how use privateobject, it's clumsy), , reading around discussion on subject there seemed fair number of people evangelising decreased use of private methods facilitate testing.

so got me thinking: primary reason locking things behind private methods other developers using object don't overwhelmed near-useless methods, right? in wpf mvvm you're invoking objects xaml, there's limited intellisense , need know names of you're calling before so.

so ... there reason using private methods when coding in paradigm? or, given 1 of key benefits of mvvm increased testability, perhaps better leave things public?

view model in mvvm type of facade on model can bound view view not have direct coupling model. provides view specific types , interfaces observablecollection, inotifyproperychanged, icommand, etc. xaml can't bind private i'm aware of. tend take think you're describing private members , place them in physically different class (or classes) classify "model". (update start) typically if sort of thing private, it's business logic. (if it's used view--ala commands--they need public).(update end) tested independently view model.

i think you'll find once won't have many tests on view model, you'd testing framework elements observablecollection, or whether interfaces implemented correctly. , in order vm use model, members need public , testable.

update: clear, there's nothing wrong "logic" in view model--just long logic supports view (or else does) directly. e.g. commands.