I’m writing a relatively simple web application made of three tiers:
- Frontend: Very thin Controllers
- Business Logic: Domain specific Services
- Storage: Thin repository Classes
As suggested above, most of the business logic is in the Services tier 2.
As I write these classes, I find myself treating READ methods very differently to WRITE methods.
READ Methods in the Service classes
For example, there aren’t overly strict argument checks in the READ methods. A lot of the time, for simple reads, the Service methods are simply implementing the Repository methods almost with just one line.
WRITE Methods in the Service classes
With the WRITE methods however I find myself doing way more argument checking, and business logic implementing. In fact in my service classes I have a dependency on a Rules class which only really gets used by my WRITE methods. There is biz logic in READS too, but logic is more strict on WRITES.
Other arguments for possibly separating READS and WRITES
I also feel like when implementing a service class and looking for a method in a class, in my mind first have an idea of whether I want to READ or WRITE, and then I look for the method.
I also feel like when looking for a method in a class, it seem messy to have to separate READS and WRITES by arbitrary method names that start with “Create”, “Update”, “Get”, “Retrieve” etc. etc.
Possible problems and, is it a good idea to separate?
I guess I’m looking for a tried and tested pattern. I could try implementing it myself, but I already feel like there could be problems, like over complicating design, or circular references, repetition of logic, eg. the READ class may depend on the WRITE class and vice versa.
Sounds like you are referring to Command Query Responsibility Segregation, CQRS
Udi Dahan has a good article to start you off here.
And MS Patterns and practices have a open source project http://cqrsjourney.github.com/ which is a pretty good example.
The drawbacks of this pattern is it can be over engineering, especially if you’re writing a “relatively simple web application”.
Udi writes another article on When to avoid CQRS and then again Why you should be using CQRS almost everywhere Hope this helps.