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?
Best Answer
In most of the MVVM Projects I have worked on, there are usually a number of "cross-cutting" libraries that are accessible to every layer of the MVVM model. This is where we would put UI helpers / Logging / general utilities such as extension methods that can be used anywhere. In our solution there would be a solution folder for each of the following:
I hope this helps.