寻找有关 Microsoft Visual Studio 解决方案和项目命名约定的建议
似乎没有任何经过验证的最佳实践来指导您如何设置解决方案、项目及其输出的程序集。 Microsoft 似乎在 VS.net 时代尝试过，但他们此后已停用此内容。对于我读到的每一种方法，我都会读到另一种方法，声称相反的方法更好，或者只关注“如果微软愿意……”但实际上没有提供任何解决方案。
看来有很多方法可以做到这一点，所有这些方法似乎都适用于不同群体的情况，因此我想我应该问一下您使用什么约定以及为什么它们适合您的情况。
我希望这将为不同情况、小型开发团体和项目到大型不同地点的开发团体和项目提供一些良好的约定。
您使用什么约定来...
- 命名您的解决方案，为什么？
- 为您的项目命名，为什么？
- 为你的程序集命名，为什么？
- 知道何时创建新项目或添加到现有项目，为什么？
- 知道何时将解决方案拆分为更小的解决方案，为什么？
- 知道何时将一个项目分解为多个项目，为什么？
需要明确的是，在这些答案中，“为什么”与“如何”同样重要。这里和其他地方发布了很多关于如何使用的答案，但很少有人说明为什么他们使用一种约定而不是另一种约定。
There doesn't seem to be any tried and true set of best practices to guide you on how to setup your solutions, projects and the assemblies they output. Microsoft seemed to have tried back in the VS.net days, but they have since retired this content. For every method I read about I read another that claims the opposite is better, or a post that only concerns itself with "if only Microsoft would..." but really provide no solutions.
It appears there are many ways to do this that all seem to work for various groups in their situations, therefore I thought I would ask what conventions YOU use and why they work for YOU in your situation.
I hope that this will provide several good conventions for different situations, small development groups and projects to large diversely located development groups and projects.
What conventions do you use to...
- name your solutions, and why?
- name your projects, and why?
- name your assemblies, and why?
- know when to create a new project or add to an existing project, and why?
- know when to split up a solution into smaller solutions, and why?
- know when to break up a project into multiple projects, and why?
Just to be clear, the WHY is just as import as the HOW in these answers. There are many answers posted on the how here and other places, very few say why they use one convention over another.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一个非常广泛的问题，但却是一个很好的问题。我将从用于 ASP.Net Web 项目的简单结构开始（MVC 看起来完全不同）。
解决方案命名对我来说不是什么大问题。我倾向于为特定目的创建解决方案，并将现有项目添加到解决方案中。如果您的解决方案超过 15 个项目（只是粗略数字），请考虑添加其中一些项目作为参考。大多数人不需要同时处理超过 15 个项目。
项目命名对我来说很重要。
我尝试在项目中使用足够的文件夹，以便可以轻松查看文件夹中的所有文件，而无需滚动解决方案资源管理器。
我的典型网络项目看起来像这样。请注意表示命名空间/可编译资源与非命名空间/可编译资源的大小写不同。
我开始越来越多地使用部分类来创建综合类，这些类可以做很多事情而不会让代码变得混乱。例如，我最近创建了一个 Web 服务，其唯一目的是将 JSON 返回给客户端，但逻辑分布在近十几个部分类中，以便更好地组织它。
希望这能让你开始。
That's a very broad question, but a good one. I will start with a simple structure that I use for ASP.Net web projects (MVC will look completely different).
Solution naming isn't a big deal to me. I tend to create solutions for a specific purpose, and add existing projects to the solutions. If your solution is over 15 projects (just a rough number) consider adding some of those projects as references. Most people don't need to work on more than 15 projects at a time.
Project Naming is a big deal to me.
I try to use enough folders in my projects so that all files in a folder can easily be viewed without scrolling the solution explorer.
My typical web project looks something like this. Note the different in casing to represent namespaced/compilable resources versus those that are not.
I've started using partial classes more and more to create comprehensive classes that can do many things without having the code be cluttered. For example, I recently created a web service whose single purpose is to return JSON to the client, but the logic is spread across almost a dozen partial classes to organize it better.
Hope that gets you started.
在我们的例子中，我们使项目名称与我们为特定程序集选择的命名空间完全相同。这样就可以轻松映射物理文件夹中类文件的位置。例如 -
CompanyName.BusinessLine.BusinessService或CompanyName.Framework.Security。因此，如果开发人员正在查看CompanyName.Framework.Security.Cryptography.cs，他可以立即找出该项目并打开该项目。In our case we keep our project names quite identical to namespaces that we chose for particular assembly. That way it becomes easy to map location of a class file in physical folder. For example -
CompanyName.BusinessLine.BusinessServiceorCompanyName.Framework.Security. So if a developer is looking atCompanyName.Framework.Security.Cryptography.cs, he can immediately figure out the project and open that project.正如蒂姆所说，这是非常广泛的。需要注意的几点：
Foo.Bar.Baz命名空间中的类可能位于项目Foo.Bar的Baz目录中>。我倾向于将项目分为：
Skeety.Common以及其他类使用的一些接口，则可能有一个Skeety.Common.Testing程序集包含类型可帮助您使用 Skeety.Common 测试类）。这导致了这些规则：在许多情况下，实际上如何拆分事物并不重要 - 但它确实有助于在计算依赖层时使设计更加清晰（因此企业逻辑程序集不应该引用 UI 程序集，但反之亦然）。
太多的项目肯定会减慢你的速度，无论是在构建时间方面还是在确定一切应该在哪里方面。项目太少会使设计不太清晰。随着时间的推移，你可能会对事情应该如何安排有更多的直觉 - 但如果我声称总是知道最好的行动方案，我会感到震惊:)
As Tim says, this is very broad. A few things to note:
Foo.Bar.Baznamespace might be in theBazdirectory of projectFoo.Bar.I tend to split into projects across:
Skeety.Commonwith some interfaces used by other classes, there might be aSkeety.Common.Testingassembly containing types which help you to test classes usingSkeety.Common). This leads to these rules:In many cases it actually doesn't matter too much how you split things up - but it does help to make the design cleaner as you work out the dependency layers (so a business logic assembly shouldn't have a reference to a UI assembly, but vice versa is fine).
Having too many project can definitely slow you down, both in terms of build times and just working out where everything should be. Having too few projects makes the design less clear. Over time you're likely to get more of a gut feeling for how things should be laid out - but I'm blowed if I'd claim to always know the best course of action :)