着眼未来的代码
基本上我们都是程序员。我要问的是，您如何构建解决方案/项目，以粗略地反映您所开发内容的结构。 您将如何在代码中描述一个类与另一个类的依赖关系，如何以几年后新接触您的项目的人能够理解的方式构建您的解决方案了解（或多或少）解决方案中的代码依赖关系？
给出第一个答案，只是为了再次提示我真正要问的问题：
我们可以在开发中使用常见的工具/框架：NHibernate、ASP.NET MVS、WPF...这将导致我们以多种方式构建代码，因此熟悉该工具的人只需查看项目（例如 VisualStudio）就会明白您的项目的基本结构。
PS：我知道图表工具、Visio 或其他工具，我的问题是：您是否从编码角度考虑过这个问题？
We all coders here, basically. What I'm going to ask you, is how you're struct you solution/project to reflect even in rough way the structure of what you develop.
How you gonna describe dependency of one class from another in code, how you gonna structure your solution in a way that after a couple of years someone new to your project is able to understand (more or less) the code dependencies in your solution?
Give the first answer, just to give another hint what I'm really asking about:
We can use common tools/frameworks in our development: NHibernate, ASP.NET MVS, WPF... which will lead us to structure the code in several way, so someone who is familiar with that tool will understand just looking on the project of, let's say VisualStudio, how your project is basiclally structured.
P.S: I'm aware of Diagram tools, Visio or whatever, my question is: do you ever think about this from coding prespective?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为了补充@Joakim 在上面的评论中的观点，实现这一点的一个关键方法确实以抽象为中心。我在所有 .NET 项目中努力做的一件事是将外部依赖项限制在 Visual Studio 中自己的项目中。这些项目注入了 IoC 容器（也通过服务定位器设置进行抽象）来实现抽象接口。
所以中心域逻辑只是内部代码。没有依赖性。基本上，该项目不引用任何内容，所有内容都引用它。这只是业务逻辑（模型、依赖项的接口，例如数据存储库等）。
然后，外部依赖项（可以是通过数据访问框架的数据库、某种外部服务，甚至只是第 3 方库，例如 IoC 容器）将在其自己的项目中使用并实现域接口它需要实施。这使依赖关系保持清晰和分离，因此可以轻松识别并可能替换它们，而无需触及内部业务逻辑。
To add to @Joakim's point in a comment above, a key way to do this really does center around abstraction. One thing I make an effort to do in all my .NET projects is to confine external dependencies to their own projects in Visual Studio. Those projects are injected with an IoC container (also abstracted with a service locator setup) to fulfill the abstracted interfaces.
So the central domain logic is just internal code. No dependencies. Basically, that project doesn't reference anything, everything references it. It's just the business logic (models, interfaces for dependencies such as data repositories, etc.).
Then an external dependency (which could be a database by means of a data access framework, an external service of some kind, or even just a 3rd party library such as the IoC container) would be used in its own project and implement the domain interfaces that it needs to implement. This keeps the dependencies clear and separated, so they can be easily identified and potentially replaced without ever touching the internal business logic.