We have two separate services in our application: one for the data model and one strictly used for authentication. We took this project from the application structure of the MS business sample.
We considered the possibility of breaking our data domain service into smaller components, but decided against it because it did not seem to add any advantages (other than reducing the size of the class of service). If you have separate data models that are completely independent of each other, then the transition along this path may make sense. Intuitively, a domain service must represent the entire domain. If your domains are independent (with a random need for a crossover ), then it is logical to separate them this way.
Regarding using context like Singleton: I tried this and eventually instantiated the class. We had no problems with this, as they all use the same basic connection. I donโt know what the โofficialโ best practice is, but thatโs how I saw it in numerous RIA applications.
Nick gotch
source share