考虑到未来的代码[关闭]答案

【问题标题】：Code with future in mind [closed]考虑到未来的代码[关闭]
【发布时间】：2011-07-16 13:02:06
【问题描述】：

基本上，我们都是这里的程序员。我要问你的是，你如何构建解决方案/项目，以粗略地反映你开发的结构。你将如何描述在代码中一个类与另一个类的依赖关系，你将如何构建你的解决方案，使你的项目的新人在几年后能够了解（或多或少）您的解决方案中的代码依赖关系？

给出第一个答案，只是为了再次提示我真正在问什么：

我们可以在开发中使用常用的工具/框架：NHibernate、ASP.NET MVS、WPF...这将引导我们以多种方式构建代码，因此熟悉该工具的人只需看看就明白了比方说 VisualStudio 的项目，您的项目的基本结构如何。

P.S：我知道图表工具、Visio 或其他工具，我的问题是：你有没有从 编码方面考虑？

【问题讨论】：

这不是假设我们没有使用接口作为抽象级别来最小化类依赖关系吗？
这不是关于最小化抽象，而是以尽可能清晰的方式表达它，因为代码只是字符集，仅此而已
我真的怀疑这个问题是否有一个正确的答案，这更像是一个讨论的开始。根据faq，这不是适合 Stack Overflow 的问题类型。
@Lasse：我不同意结束这个问题。这个问题（我如何组织项目和代码，以便最容易识别其结构和各部分的关系）是软件开发所独有的，并且非常容易回答并且面临许多开发人员的实际问题（引用常见问题解答）。可能没有唯一且单一的可能答案（许多编程问题也是如此）这一事实不足以称之为讨论。投票支持重新开放。
请@downvoter 小心解释它是反对票，还是只是因为爱好而反对票？

【解决方案1】：

在上面的评论中补充@Joakim 的观点，实现这一点的关键方法确实以抽象为中心。我在所有 .NET 项目中努力做的一件事是在 Visual Studio 中将外部依赖项限制在他们自己的项目中。这些项目被注入了一个 IoC 容器（也通过服务定位器设置进行了抽象）来实现抽象的接口。

所以中心域逻辑只是内部代码。没有依赖关系。基本上，该项目不引用任何内容，所有内容都引用它。它只是业务逻辑（模型、依赖关系的接口，例如数据存储库等）。

然后在自己的项目中使用外部依赖项（可以是通过数据访问框架的数据库、某种外部服务，甚至只是第三方库，例如 IoC 容器）并实现它需要实现的域接口。这使依赖关系保持清晰和分离，因此可以轻松识别并可能替换它们，而无需触及内部业务逻辑。

【讨论】：

这是通过使用 IoC 框架“强制执行”代码结构的方法之一，同意。投票给这个，因为它很好，也只有一个。没有人真正关心这里的这些东西。可能，真的，最好在常见问题上提出这个问题。谢谢！