WCF and the Domain Model - doesnt it need to be Anemic?

Here is the argument against an Anemic Domain Model as presented by Martin Fowler (read link).

Now based on this description, one would expect the business object to not just have getters and setters, but also behavior, such as what I show below.

    public clas开发者_运维技巧s Student
{
    private List<Course>_courses = new List<Course>();
    public string Name{get; set;}
    public ReadOnlyCollection<Course> Courses {
        get{ return _courses.AsReadOnly();}
    }
    public void Add(Course course)
    {
        if (course != null && _courses.Count <= 3)
        {
            _courses.Add(course);
        }
    }
    public bool Remove(Course course)
    {
        bool removed = false;
        if (course != null && _courses.Count <= 3)
        {
            removed = _courses.Remove(course);
        }
        return removed;
    }
}

But an object like the Student as described above cannot be properly exposed via a WCF service call (Courses is exposed only via a readonly property). Which would mean that I need to have a Courses getter and setter which returns a List

So isnt the Anemic domain model appropriate for WCF and a proper domain model appropriate only when the client can actually use the code (Asp.net when server side or in the client side business entities when using Silverlight, etc).

So isnt the Anemic domain model appropriate for WCF

In this context, what you call Anemic Data Model, I'd call Data Transfer Object.

Domain model captures behavior and the data that drives the behavior. Often exposing a domain model as-is over a remote endpoint often suffers from too much coupling and runs into practical problems.

Often Data Transfer Objects (DTO) (http://martinfowler.com/eaaCatalog/dataTransferObject.html) is a good way of solving that design tension.

There will end up being code that walks your domain model properties and copies the data over to the appropriate DTO for return to the caller of your WCF service.