1

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?

1

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:

  • Host (This is where the executable will reside)
  • DA ( Data Access Layer)
  • BL (Business Layer, the Model)
  • PL (Presentation Layer, the ViewModels)
  • UI (User Interface, the Views)
  • Services (This is where all of the cross cutting code would be hosted, e.g. MyProject.Services.UIHelpers)

I hope this helps.

  • Thanks, you confirm the way I am currently doing things isn't batshit crazy. And oh so not proper MVVM. – ProfK Jan 25 '14 at 16:00
  • Not a problem, I see using MVVM as something that can be built upon rather than a strict set of rules as to how the application can be developed. Things like custom exception definitions and logging cannot be forced into the MVVM structure and as such you will need to develop a set of libraries that are outwith the MVVM paradigm. – stuartmclark Jan 25 '14 at 17:15
  • Yes, I have started that, but it proves one of the more challenging aspects of working in MVVM. I don't want a billion references to 'helper' libraries in each MVVM layer component. Sharing files through symlinks proved close to useless, but I think sharing projects like that might prove more fruitful. – ProfK Jan 26 '14 at 5:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.