Your business has no place within the MVVM application. You business should be factored out into a separate class library. This has many benefits which I could explain in case you want me to.
So anyway, here's how your solution's structure should look like:
- [Project].Shared: Service Contracts and Object Model
- [Project].Data: Interfaces of your data access layer.
- [Project].Data.Sql: SQL implementation of your data access layer. If you are using Oracle, that would be [Project].Data.Oracle. Catch the drift?
- [Project].API: Business managers. ALL of your application's business should be encapsulated and isolated in this layer.
- [Project].Services: Service implementations.
- [Project].UI.MainApplication: Your WPF main application.
- [Project].UI.Shared: Has all what is common among all of your WPF client applications. Moreover, you should add the Object Model classes and Service Contract interfaces as links into this project.
- [Project].UI.[OtherApp]: In case you want to separate your UI into modules (I strongly recommend that).
Basically, the "M" in MVVM will be the Object Model itself, unless a View needs some model which comprises properties from different objects... etc.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…