By non-MVVM code, I mean things like highly generalized components, like one with common extension methods for CLR types, and other 'homeless' helper classes etc? I have a Core project that most others reference, but to resolve circular dependencies I had to refactor the extensions to another project. This seems a common challenge in a well layered project.In some cases it's easier and produces a better project structure to have one copy of a class in each of two or more components, and I can't use symlinks for these copies because the namespace differs.Or else I'm going to end up with quite a fat Core project, hosting disparate groups of helper classes. Down to what granularity can I factor these out and increase the dependency count of clients of these servives. What is a general convention here?
Where does non-MVVM code belong in an MVVM app?
architecture;wpf;mvvm;layers