组织这个项目的最佳方式是什么？
我目前正在尝试找出组织我目前正在进行的项目的最佳方式。它将成为人们可以使用的 SDK。
然而，我在组织这个项目时有点困难。我有一些命名空间和一些项目。这些项目编译成不同的 DLL。
当我编译所有程序集时，我有以下程序集：
Application
Application.Entities
Application.DataAccess
但是，在这些程序集中仍然有一些不同的名称空间，例如，
Application.DataAccess.SourceProviders
Application.DataAccess.SourceParser
所以如您所见，我对此不太一致。我不会为每个命名空间创建不同的程序集，因为我觉得拥有 10 个以上的 dll 不会增加任何价值。
但我对此有几个问题，以便我可以决定如何去做。
- 对应用程序的不同部分使用不同的程序集，而不是仅使用 1 个包含所有程序集的 DLL，有哪些优点？
- 通过使用不同的项目（cq 程序集/dll）将 DAL 与逻辑分离是个好主意吗？
- 您是否有一些有关 VisualStudio 或 SDK 设计中的项目组织的信息来源？
干杯，
蒂莫
I'm currently trying to find out the best way to organize a project I'm currently working on. It's going to be an SDK that people can use.
However, I'm a little bit strugling with organizing the project. I'm having a few namespaces and a few projects. These projects compile into different DLL's.
When I compile all I have the following assemblies:
Application
Application.Entities
Application.DataAccess
However, in those assemblies are still a few different namespaces, like
Application.DataAccess.SourceProviders
Application.DataAccess.SourceParser
So as you can see I'm not being very consistent with this. I'm not creating a different assembly for every namespace, because I feel it adds no value having 10+ dll's.
But I have a few questions about this here so I can make a decision on how I'm going to do it.
- What are the advantages of using different assemblies for different parts of the application, in stead of using just 1 DLL that contains ALL.
- Is it a good idea to seperate the DAL from the logic, by using a different project (cq assembly/dll).
- Do you perhaps have some sources of information about project organisation in VisualStudio or SDK design.
Cheers,
Timo
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这很大程度上取决于个人喜好，但我会尝试一下：
如果您需要单独维护 DLL，或者需要分发不同版本的代码，那么将它们隔离是有意义的。如果您能够动态加载程序集并希望能够从不同的发行版中排除某些 DLL（例如，根据用户的许可添加或删除功能），那么这提供了一种便捷的方法来执行此操作，而无需依赖编译标志或不同的构建配置 - 只需删除您不希望用户拥有的 DLL。
缩小各个库的代码大小可能会对 JIT 产生影响，但我对此并不乐观。也许其他人可以插话。
层可见性应该是这样的：每一层都可以看到其下方的所有内容，但看不到上方的任何内容：
一般来说，每一层只能与直接位于其下方的一层通信，并且只能由直接位于其上方的一层调用。
现在，假设您有一组这样的应用程序：
通过将通用对象和 DAL 分离到单独的程序集中，可以轻松地从不同的项目或解决方案中引用它们。在这种情况下，Web 服务应用程序（可能旨在从非 .NET 客户端或第 3 方网站调用）如果不需要 BL，可以直接转到 DAL，而其他应用程序可以转到 BL ，然后穿过其他层。
能够在不同类型的应用程序之间共享代码（全部使用 .NET 语言编写）是 .NET 独有的非常非常强大的功能。 Web 特定的代码可以存储在其自己的库集合中，桌面特定的代码等也可以存储在其中。将每一层分成一个或多个程序集可以让您将新项目修补到有意义的管道中的任何位置，并确保您不会例如，在分发客户端应用程序时，不必包含
system.web以便应用程序能够编译。当我的老板在会议期间不再盯着我打字时，我会尝试找到一些链接。
A lot of this comes down to personal preference, but I'll take a shot:
If you need to maintain the DLLs separately, or if you need to distribute different versions of the code, then it makes sense to keep them isolated. If you have the ability to load assemblies dynamically and want the ability to exclude some DLLs from different distributions (to add or remove features depending on the user's licensing, for instance), this provides a convenient way to do that without relying on compilation flags or different build configurations - just remove the DLLs that you don't want the user to have.
Keeping code size down for individual libraries may have an impact on JIT, but I'm not positive about that. Perhaps someone else can chime in.
Layer visibility should go like this: each layer can see everything below it, but nothing above:
In general, each layer should only talk to the one directly below it, and should only be called by the one directly above it.
Now, imagine you have a set of applications like this:
By separating the generic objects and DAL into separate assemblies, it's easy to reference them from different projects or solutions. In this case, the web service app (perhaps intended to be called from non-.NET clients or 3rd-party websites) can go directly to the DAL if it doesn't need the BL, while the other apps can go to the BL, then through the other layers.
Being able to share code between different types of applications, all written in a .NET language, is a very, very powerful feature that is unique to .NET. Web-specific code can be stored in its own collection of libraries, as can desktop-specific code, etc. Separating each layer into one or more assemblies lets you patch new projects anywhere into the pipeline that makes sense, and ensures that you don't have to include, say,
system.webwhen distributing a client app just so that the application will compile.I'll attempt to find some links after my boss stops staring at me typing during a meeting.
使用不同程序集的主要优点是可以分解大型项目 - 不同的团队或部门可以处理单独的组件。
是的。您的业务逻辑应该与 DAL 分开。它对于架构原因以及单元和单元很有用。集成测试。
这是非常主观的，取决于您的项目、团队、组织结构、业务需求等的规模。
The main advantage of using different assemblies is for breaking down large scale projects - different teams or departments can work on separate components.
Yes. Your business logic should be seperate from your DAL. It's useful for architectural reasons as well as Unit & Integration Testing.
This is very subjective and depends on the size of your project, team, organisational structure, business requirements, etc.
如果您要在多个项目中重用该 dll，那是肯定的。如果您希望能够更新/修补而不可能导致其他库回归，那是肯定的。这本质上是一个粒度问题。
我通常会这样做，主要是为了单元测试粒度，原因在 #1 中。
我发现这个有一些见解，尽管我并不完全同意。与所有 TFS 一样，我认为它通常太多了。
我认为命名空间本质上是一种文档形式 - 通过指示命名空间，您可以期望该命名空间的所有成员都有一些共同点。
If you're going to reuse that dll in multiple projects, definitely. If you want to be able to update / patch without the possibility of causing regression in other libraries, definitely. It's essentially a question of granularity.
I generally do, mostly for unit test granularity, and the reasons in #1.
I have found this to have some insight, though I don't agree with all of it. As with all of TFS, I think it's generally JUST TOO MUCH.
I think that namespaces are essentially a form of documentation - by indicating a namespace you're setting the expectation that all of the members of that namespace have something in common.