Agreed: Use namespaces for logical organization, not projects. One approach is to think of projects as units of deployment. Will Project.Client always be deployed with Project.ViewModels? Project.Models? Is one referencing the other? Just include in the same project and use namespaces for organization.
A few reasons why you may want to separate Silverlight class libraries/applications into individual projects:
Reuse. You want to develop APIs that will be used for other applications. Your Project.Infrastructure may fall into this category.
Modularity. MajorFunctionA is only used by the end user 20% of the time. Maybe only certain authenticated users have access. Maybe it is only access when navigated to a specific page that noone goes to. You could choose to build into separate Silverlight apps and only download the .xaps as needed using frameworks like MEF or PRISM.
Developer Workflows. One team in one city/office is working on Project.Client and another team in another city/office is working on Project.Models. It might make sense to build into separate projects to make life easier.
One other thing to note about assemblies is that you can't have circular references between assemblies. In other words, if ClassA and ClassB are in the same assembly, ClassA can reference ClassB, and ClassB can reference ClassA. But if they're in separate assemblies, they can't. Now, if your classes have a lot of circular references, that's probably not a good thing, but sometimes it's difficult to avoid, and your options are much more limited if they happen to be in separate assemblies. But on the flip side, increasing the number of assemblies limits the opportunity for circular references, which can improve the quality of your design. Just something else to be aware of.
Following that logic, one alternative would be grouping Project.Client, Project.Data, Project.Model, Project.UIControls, and Project.ViewModels in one project and grouping Project.Common and Project.Infrastructure into another. MajorFunctions could be left separate or grouped into Project.Client. You would end up with:
Project.Client - Application specific interface, view models, and models.
Project.Infrastructure - Common, reusable helpers, converters, and interfaces.
Project.UnitTests
Project.Web
Project.Web.Infrastructure
Also. There's not really a correct answer for this. I'm tagging as Community Wiki.
发布评论
评论（1）
同意：使用命名空间进行逻辑组织，而不是项目。一种方法是将项目视为部署单元。 Project.Client 是否始终与 Project.ViewModels 一起部署？项目.模型？一个引用另一个吗？只需包含在同一个项目中并使用命名空间进行组织即可。
您可能希望将 Silverlight 类库/应用程序分离到单独的项目中的几个原因：
关于程序集需要注意的另一件事是程序集之间不能有循环引用。换句话说，如果ClassA和ClassB在同一个程序集中，ClassA可以引用ClassB，ClassB可以引用ClassA。但如果它们位于不同的程序集中，则不能。现在，如果您的类有很多循环引用，这可能不是一件好事，但有时很难避免，并且如果它们碰巧位于单独的程序集中，您的选择会受到更多限制。但另一方面，增加装配数量会限制循环引用的机会，而循环引用可以提高设计质量。只是还有其他需要注意的事情。
按照这一逻辑，一种替代方案是将 Project.Client、Project.Data、Project.Model、Project.UIControls 和 Project.ViewModels 分组到一个项目中，并将 Project.Common 和 Project.Infrastruct 分组到另一个项目中。 MajorFunctions 可以分开或分组到 Project.Client 中。您最终会得到：
也。这个问题并没有真正正确的答案。我将其标记为社区 Wiki。
Agreed: Use namespaces for logical organization, not projects. One approach is to think of projects as units of deployment. Will Project.Client always be deployed with Project.ViewModels? Project.Models? Is one referencing the other? Just include in the same project and use namespaces for organization.
A few reasons why you may want to separate Silverlight class libraries/applications into individual projects:
One other thing to note about assemblies is that you can't have circular references between assemblies. In other words, if ClassA and ClassB are in the same assembly, ClassA can reference ClassB, and ClassB can reference ClassA. But if they're in separate assemblies, they can't. Now, if your classes have a lot of circular references, that's probably not a good thing, but sometimes it's difficult to avoid, and your options are much more limited if they happen to be in separate assemblies. But on the flip side, increasing the number of assemblies limits the opportunity for circular references, which can improve the quality of your design. Just something else to be aware of.
Following that logic, one alternative would be grouping Project.Client, Project.Data, Project.Model, Project.UIControls, and Project.ViewModels in one project and grouping Project.Common and Project.Infrastructure into another. MajorFunctions could be left separate or grouped into Project.Client. You would end up with:
Also. There's not really a correct answer for this. I'm tagging as Community Wiki.