Exactly what you pull into memory is governed by your database mapping software. Usually it's better to pull in a little more than you need in order to reduce calls between the application and the database. If you need the same object graph between calls to the server, you'll need to save the server state somewhere, which is the subject the section on saving server state. One variation you often come across is between context dependent and context independent classes. This boils down to whether you use the same contract class for all sessions, or use different contract classes with different data and behavior using only what's needed for that session.
Most people use context independent classes that are the same for all sessions.
Otherwise it's too easy to forget which behavior is on what context and to duplicate stuff across contexts. If an object is sufficiently complex and can be partitioned well for different sessions, then it is perhaps worth considering - but I would do it only as an exception case. When to Use it If the how for a Domain Model is difficult because it's such a big subject, the when is hard due to both the vagueness and simplicity of the advice. In a nutshell it all comes down to the complexity of the behavior in your system. On the other hand if you just have a simple not null checks and a couple of sums to calculate, then a Transaction Script is a better bet.