Mileage Stats has two model - one the data model (in MileageStats.Model) and a domain model (in
MileageStates.ServicesModel). The data model is anemic because we use the
DbModelBuilder to define the schema, and avoid incorporating business or application logic in the data tier. The domain model is not anemic as it contains calculated properties, validation attributes, etc. The domain model may seem
thin compared to a domain model for a desktop client application. The nature of the request/response pipeline for web applications and services means that a traditional domain model would create a connected object graph on each request. We wanted
to limit the data loaded per request to just the parts of the domain model needed for communication to and from the client. We also wanted the ability in the future to possibly expose application logic as a separate service. For these reasons, most of
the business logic was factored into a business services layer (in MileageStats.Services) which implements interfaces (in
We are currently working on the web guidance book (and help topics) that will explain the domain and data models in more detail (see the Drop 8 Server-side Architecture chapter). However, it would be helpful if you can provide more details on what
aspects of the domain model you found confusing.
Were you confused by there being both a domain and a data model?
Was the class hierarchy of the domain model confusing?
Are there code comments in the domain model you think we should add to clarify its purpose?
Is there a different architectural approach to separating concerns that you are more familiar with - possibly that we could compare/contrast to?
Thanks for you feedback,
on behalf of Microsoft Patterns & Practices