.net 构造webapp对象模型的好方法是什么？

我正在努力寻找一种在我正在开发的webapp中构造对象模型/web服务的好方法。我们有一个共同的问题，不同的页面需要一个标准对象稍微不同的视图。例如，我们有团队和组织类型，其中一个组织可以有一对多个团队。在一页上，我需要的是

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

但在另一页中，我需要一个不同的数据投影，例如

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

通常情况下，对象的投影跨越多个表。我的想法是，查询并传递团队和组织的所有数据，然后只使用页面上需要的部分是不好的。看起来我最终会遇到大量不必要的数据被查询并在系统中流动

我当前的模型是为每个投影创建单独的类型。我喜欢类型安全性，但我遇到的问题是，我有团队、SimpleTeam、团队和组织等类型。我以团队/组织为例，但我发现我的系统中许多不同类型都存在相同的问题

---

你是怎么处理的？我使用WCF在webapp和后端系统之间传递数据。

虽然我通常认为每个视图模型是一个好方法，但在服务环境中，我会有点担心这一点。理想情况下，我认为您希望您的服务更加通用，这样您就不会得到大量的方法，每个视图一个。一般来说，如果这意味着我可以使我的服务更通用的话，我愿意提供比需要多一点的数据。在我的例子中，我有不同类型的客户端（移动和标准web应用程序），它们通常获得相同的数据，但移动应用程序使用的是减少的子集。在这种情况下，我不提供单独的模型，但移动应用程序不使用某些数据。

我不会将您的对象模型绑定到页面视图。一旦你这样做了，就很难或不可能改变你的页面。这是层与层之间的微妙耦合，应该避免

---

也许可以过滤最终到达客户端的数据。来自数据库的延迟评估也会有所帮助。

它肯定会导致服务方法的爆炸，这是可怕的。我是否过度担心性能/可伸缩性，担心额外的数据四处浮动。产品销路很好，我们的用户群稳步增长。如果我们继续我们的课程，明年我们将看到1000多名并发用户。您需要在性能和可维护性之间取得平衡。一般来说，我会使用可维护性，直到性能成为一个问题，然后根据需要进行重构以提高性能。哇，似乎无论我读/听了多少次，总体想法（过早优化是万恶之源）都不会在我的设计中产生共鸣。非常感谢。因为我已经用web服务将webapp与数据库分离，所以从DB进行惰性评估似乎不是一个选项。我希望更多地重复使用我的“投影”，但没有看到太多（即：你对耦合非常着迷）。然而，这似乎使更改页面更容易，而不是更难。我不必担心对其他页面的副作用，因为它们都使用自己的数据投影。如果您的web界面完全消失，被Flash或Flex UI取代，或者您决定添加一个并行、更简单的移动界面，会发生什么？你的设计将如何应对这些变化？这将是一个巨大的痛苦！我误解了你所说的难以/不可能“更改”页面的意思。我正在考虑调整我现有的页面。没错。你的应用程序比你的界面停留时间长的可能性有多大？想一想。