Hi!

We are developing a desktop application that uses WCF services as a service layer. Service proxies are injected into the application viewmodels, making them pretty slim, mostly just commands, revents and viewmodel specific properties.

We are having a problem with the services, they are getting very bloated.

For example, we have a SaveMeasurementAsync(measurement as Measurement) method in the service layer, that takes an object full of sampled measurements. Currently that method does the following things:

* Saves the measurements in the database (through a repository)

* Sends a MSMQ message

* Composes the MSMQ message by 15 lines of string concatenation

* Sending an email (by using another EmailHelper class)

* Has some logic that determines if to send an email or not


All this in the 320 line method, which makes it a living hell to unit test. My question to you guys is, how to refactor? The obvious thing would be to break out stuff into separate classes and inject those into the MeasurementService (we use Unity as DI container), but that may cause another problem that the MesaurementService is getting way too many dependencies. And both me and my colleague are lousy at coming up names for classes to break up the code into. Usually we just move stuff into private methods, but that is an anti pattern itself and doesn't really solve the problem, the MeasurementService still is a "god" class, only the single method has less code.

So, some solid questions:

1) Exactly what should the MeasurementService class do?

2) What other classes could the logic be split up into? I would really appreciate some suggestions on names, or some patterns to follow? We really want to follow the single responsibility principle, but we have noticed that it is easier said than done.


We have another project with the exact same symptomes, but there we don't use WCF, so in that case the viewmodels are the ones that does "everything". One viewmodel has 3000 lines of code and 29 private methods. No one has even thought about writing unit tests for that one.


We are getting desperate here, and would really appreciate your help guys!!!

/Henrik