Silverlight 应用程序项目结构 - 多少才算太多？

Question

我的团队正在努力创建我们的第一个 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”之类的事物，它只是应用程序的一个小组件，为什么它应该有自己的项目。 （请记住，该特定功能的视图和 ViewModel 不会存在于该项目中，而是存在于其他 Client/ViewModel 项目中。

我们只是在寻找一些验证，因为我没有看到任何原因。

Answer 1

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

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

• 重复使用。您想要开发将用于其他应用程序的 API。您的 Project.Infrastructure 可能属于此类。
• 模块化。 MajorFunctionA 仅在 20% 的时间内由最终用户使用。也许只有某些经过身份验证的用户才能访问。也许只有在导航到没有人访问的特定页面时才能访问。您可以选择构建到单独的 Silverlight 应用中，并且只根据需要使用 MEF 或 PRISM 等框架下载 .xap。
• 开发人员工作流程。一个城市/办公室的一个团队正在开发 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 - 通用、可重用的助手、转换器和接口。
• Project.UnitTests
• Project.Web
• Project.Web.Infrastructure

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