将代码片段划分为单独项目的典型经验法则
我想知道何时将项目的代码和组件划分为单独的项目。我正在创建一个 MVC .NET Web 项目，有很多目录/子目录，我什至还没有开始进入一些需要更多空间的后台进程。
我只是想致力于组织项目和内部代码。
什么时候应该开始将代码划分为单独的项目？您还可以举个例子吗？
谢谢
I'm wondering when to divide code, and components of a project into a separate project. I'm creating a MVC .NET Web project, and there are many directories/sub-directories, and I haven't even started getting into some of the background processes that will take even more space.
I'm just trying to work on organizing projects and the code-within.
When should you start dividing your code into separate projects? Could you also provide an example?
Thank You
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我经常看到类似以下内容的变化：
获得想法的一种方法是搜索 asp.net MVC 开源项目，看看他们是如何做的。
对于上述的替代方法，您可以查看 CodeCampServer。他们使用洋葱架构来布局他们的项目。
洋葱架构与上面列出的不同，他们有一个很好的 解释原因（网络广播）。
取自上面引用的网页的图片。
洋葱架构与开源示例的链接为您提供了何时/为何的推理，以及一个具体的示例来看看您是否喜欢它。
I often see a variation on something along the lines of:
One way to get an idea is search for asp.net MVC open source projects and see how they are doing it.
For an alternate way to above you can check out CodeCampServer. They used the Onion Architecture to layout their projects.
The Onion Architecture is different than what was laid out above and they have a great explanation of why (webcast).
Pictures taken from web page referenced above.
The Onion Architecture link with the open source sample gives you reasoning behind when/why and a concrete example to play with to see if you like it.
在我的应用程序中，将代码分成不同项目的目的通常是为了实现代码重用。实际上，没有任何硬性规定，但这里有一些我尝试遵循的原则。
对于代码重用，我会考虑我编写的类是否可以在不同的上下文中使用。例如，如果我有一个与数据库通信的 ASP.NET 网站，则数据访问代码可能会在基于 Windows 的应用程序中重用，因此将其纳入自己的库中是一个不错的选择。
我创建扩展方法来方便地操作字符串、流或其他常见的东西。我将这些因素纳入一个库中，以便在所有应用程序中通用。
总之，尝试将项目组织成高度内聚的相关类集合，并避免创建包办一切的项目。您会发现高度凝聚力的项目更有可能被重用，从而节省您的时间和雇主的金钱。
Most often in my apps, the purpose of separating code into different projects is to accomplish code reuse. There aren't any hard-and-fast rules, really, but here are some principles I try to follow.
For code reuse, I consider whether a class I write is usable in a different context. For example, if I have an ASP.NET website that communicates to a database, the data access code might be reused in a windows-based application, so it is a good candidate to factor into its own library.
I create extension methods for convenient manipulation of strings, streams, or other common things. These, I factor into a library for common use across all applications.
In summary, try to organize your projects into highly-cohesive collections of related classes, and avoid creating do-everything projects. You'll find that the highly-cohesive projects are more likely to be reused, saving you time and your employer money.