1

我的团队正在努力创建我们的第一个 Silverlight 4 应用程序。首先介绍一下实际项目的一些细节。它将是 Silverlight 4，旨在运行 Out-oF-Browser，我们将使用 WFC 和我们自己的 Dataobjects 实现来提供数据服务。（没有实体框架、LINQ-to-SQL 等）。我们有一些顾问正在推荐一个包含超过 11 个单独项目的解决方案结构。对我们来说，似乎没有理由这样做，任何人都可以看到为什么可能需要类似以下内容的任何理由吗？

  • Project.Client - 资产、样式、视图
  • Project.Common - 转换器、助手
  • Project.Data - 未知用途（客户项目）
  • Project.Infrastructure - 命令、常量、接口、日志
  • Project.MajorFunctionA - “应用程序主要功能 A 的业务逻辑”
  • Project.MajorFunctionB - “应用程序主要功能 A 的业务逻辑”
  • Project.MajorFunctionC - “应用程序主要功能 A 的业务逻辑”
  • Project.Models - 对 WCF 服务的抽象访问
  • Project.UIControls - UI 的自定义控件
  • Project.UnitTests - “可能所有单元测试”
  • Project.ViewModels - UI 的视图模型
  • Project.Web - silverlight 应用程序的宿主项目 - 无代码
  • Project.Web.Infrastructure - 数据对象和 WCF 服务

现在，我们的主要困惑是为什么我们不只是将它们命名空间以将它们分开，以及像“Project.MajorFunctionA”这样的东西，它只是应用程序的一个小组件，为什么它应该有自己的项目。（请记住，该特定功能的视图和视图模型不会存在于该项目中，而是存在于其他客户端/视图模型项目中。

我们只是在寻找一些验证，因为我看不出有任何理由。

4

1 回答 1

3

同意：使用命名空间进行逻辑组织，而不是项目。一种方法是将项目视为部署单元。Project.Client 是否始终与 Project.ViewModels 一起部署？项目模型？一个引用另一个吗？只需包含在同一个项目中并使用命名空间进行组织。

您可能希望将 Silverlight 类库/应用程序分成单个项目的几个原因：

  • 重复使用。您想要开发将用于其他应用程序的 API。您的 Project.Infrastructure 可能属于此类。
  • 模块化。MajorFunctionA 仅在 20% 的时间内由最终用户使用。也许只有某些经过身份验证的用户才能访问。也许只有在导航到没有人访问的特定页面时才能访问。您可以选择构建到单独的 Silverlight 应用程序中，并且只根据需要使用 MEF 或 PRISM 等框架下载 .xaps。
  • 开发人员工作流程。一个城市/办公室的一个团队正在开发 Project.Client，而另一个城市/办公室的另一个团队正在开发 Project.Models。构建单独的项目以使生活更轻松可能是有意义的。

关于程序集要注意的另一件事是程序集之间不能有循环引用。也就是说，如果 ClassA 和 ClassB 在同一个程序集中，ClassA 可以引用 ClassB，ClassB 可以引用 ClassA。但是，如果它们在单独的程序集中，则不能。现在，如果您的类有很多循环引用，这可能不是一件好事，但有时很难避免，而且如果它们碰巧在单独的程序集中，您的选择就会受到更多限制。但另一方面，增加组件的数量会限制循环引用的机会，这可以提高您的设计质量。只是需要注意的其他事情。

按照该逻辑，一种替代方法是将 Project.Client、Project.Data、Project.Model、Project.UIControls 和 Project.ViewModels 分组到一个项目中，并将 Project.Common 和 Project.Infrastructure 分组到另一个项目中。MajorFunctions 可以单独或分组到 Project.Client 中。你最终会得到：

  • Project.Client - 特定于应用程序的界面、视图模型和模型。
  • Project.Infrastructure - 通用的、可重用的助手、转换器和接口。
  • 项目.UnitTests
  • 项目网站
  • Project.Web.Infrastructure

还。对此并没有真正的正确答案。我标记为社区 Wiki。

于 2010-09-30T00:05:10.643 回答