What is a good way to structure my webapp object model?

I'm struggling to decide on a good way to structure my object model / web services in a webapp I'm working on. We have a common issue where different pages need a slightly different view of a standard object. For example, we have Team and an Organization types where an Organization can have one-to-many Teams. On one page all I need is something like

class Team {
    long TeamID { get; set; }
    string Name { get; set ;}
    TeamType TeamType { get; set; }
}

But in another page I need a different projection of the data such as

class Team {
    long TeamID { get; set; }
    string Name { get; set ;}
    string OrganizationName { get; set; }
    string TeamPicture { get; set; }
}

Often times the projection of an object spans multiple tables. My thought is that it is bad to query out and pass around ALL of the data for a Team and Organization and then just use the parts I need on the page. It seems like I'll end up with huge amounts of unnecessary data being queried and flowing around the system.

My current model is to create separate types for each projecti开发者_如何学运维on. I like the type safety but the problem I'm running into with this is I've got types like Team, SimpleTeam, TeamAndOrganization, etc. I'm using team/organization as the example, but I find the same problem with many different types in my system.

How do you handle this? I use WCF to pass data between the webapp and a back-end system.

---

While generally I think model-per-view is good way to go, I'd be a little concerned about this in the context of a service. Ideally, you'd like your service to be more general I would think so that you're not getting an explosion of methods, one per view. Generally, I'm willing to provide a little more data than necessary if it means that I can make my service more general. In my case, I've got different types of clients (mobile vs. standard web app) and they generally get the same data, but the mobile app uses a reduced subset. In this case I don't provide separate models, but the mobile app just doesn't use some of the data.

---

I would not tie your object model to a page view. Once you do that, it's difficult or impossible to change your pages. It's a subtle coupling between layers that should be avoided.

Perhaps it's possible to filter the data that ends up at the client. Lazy evaluation from the database can help as well.