When we had to confront this decision, we went with creating view models that encapsulated/mirrored our business objects. This gives us more control over how the objects should look when serialized in json without having to add view logic in our business layer.
Example: Suppose we had a Person business object:
public class Person
{
public int Id {get;set;}
public string Name {get;set;}
}
When a client is going to consume our web service, we wouldn't want them to know what the Id
value is, since that's an internal database key. The two options we considered for fixing that is 1) add a [ScriptIgnore]
attribute onto Person.Id
property or create a separate view model for our Person, which is custom-tailored to the view domain.
We stayed away from option 1 because we didn't want to add view logic in our business layer for much of the same reason you don't... our business layer isn't directly tied to our presentation layer.
This is a very simplified scenario, but the larger idea is still intact. With separate view models you have the ability to include/exclude data in your view without hampering the cleanliness of your business layer.