.NET 项目/命名空间组织问题
我们有一个定义了许多接口和一些基本默认实现的框架。我们称之为 CompanyFramework。我有一些 ASP.NET MVC 扩展，当前存储在单独的项目 CompanyFramework.Web.Mvc 中。这样做的原因是，使用核心框架但与 MVC 无关的应用程序不必引用 ASP.NET MVC 库。我不太喜欢这种设置，因为额外的程序集仅包含 3-4 个类文件，但这是避免为主框架程序集引入不必要的依赖项的最干净的方法。
现在，我们有一些用于 ASP.NET MVC 的 StructureMap 特定扩展，即自定义控制器工厂和模型绑定器类型内容。你会把这样的东西放在哪里？我可以将它扔到 CompanyFramework.Web.Mvc 项目中，但是任何使用它的 ASP.NET MVC 项目都会引用 StructureMap 程序集，即使它没有被使用。我还可以创建一个单独的 CompanyFramework.StructureMap 项目，但是如果我开发了任何不依赖于 ASP.NET MVC 的 StructureMap 扩展，我仍然不愿意为使用它们的类引用 MVC 程序集。
我应该创建一个单独的 CompanyFramework.Web.Mvc.StructureMap 项目吗？这种方法总体上看起来最干净，但我觉得我开始引入一堆轻量级卫星组件，这些组件使整个项目结构变得混乱。
We have a framework that defines many interfaces and some basic default implementations. Let's call it CompanyFramework. I have some ASP.NET MVC extensions, currently stored in a separate project CompanyFramework.Web.Mvc. The reason for this is so that applications that use the core framework but have nothing to do with MVC don't have to reference the ASP.NET MVC libraries. I don't really like this setup, as the extra assembly only contains 3-4 class files, but it was the cleanest way to avoid introducing unnecessary dependencies to the main framework assembly.
Now, we have some StructureMap-specific extensions we use for ASP.NET MVC, namely custom controller factories and model binder type stuff. Where would you put something like that? I Could just throw it in the CompanyFramework.Web.Mvc project, but then any ASP.NET MVC project that uses that would have a reference to the StructureMap assembly, even if it isn't being used. I could also create a separate CompanyFramework.StructureMap project, but then if I ever develop any extensions to StructureMap that don't depend on ASP.NET MVC, I'm still suck with referencing the MVC assemblies for the classes that do use them.
Should I make a separate CompanyFramework.Web.Mvc.StructureMap project? This approach seems cleanest overall, but I feel like I'm starting to introduce a bunch of lightweight satellite assemblies that are cluttering the overall project structure.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
更糟糕的是，不良的依赖关系还是一些额外的项目？稍微混乱的 IDE 是为定义良好的结构付出的很小的代价。
What's worse, bad dependencies or a handful of extra projects? A slightly cluttered IDE is a small price to pay for a well defined structure.
对于任何这样的问题，我发现考虑该决定对未来修改的长期影响是有帮助的。最终，其中一些库将被废弃和替换，而其他库将继续存在。例如，某些技术将会取代 MVC。
我相信，将这些东西分开将使未来的开发人员和维护人员的生活变得更加轻松。依赖关系将更加明确（这总是一件好事），并且可以更加自信和清晰地做出迁移决策。
此外，出于许多其他原因，您不会希望在未来的每个项目中都使用不断扩展的 Big Ball of Mud 库。对我来说，“一堆轻量级组件”听起来像是一个出色的设计目标。
On any question like this I find it is helpful to consider the long-term implications of the decision with respect to future modifications. Eventually, some of these libraries will be obsolesced and replaced, while others will live on. Some technology will come along that will replace MVC, for example.
I believe that keeping these things separate will make the lives of those future developers and maintainers a lot easier. The dependencies will be more explicit (which is always a good thing), and migration decisions can be made with greater confidence and clarity.
Also, an ever-expanding Big Ball of Mud library is not something that you will want to tack on to every project in the future for lots of other reasons. A "bunch of lightweight assemblies" sounds like an excellent design goal to me.
我建议将 StructureMap 与 MVC 项目放在一起。我认为这在逻辑上是最有意义的，并且在某些情况下拥有未使用的引用不会成为问题。
我认为你当前的设置（CompanyFramework 程序集 + MVC 程序集）非常合理。我发现我最终遵循同样的模式：通用程序集、Web 程序集（或专门针对 MVC 或 Web 表单）、数据库程序集等。像这样在高功能级别将它们分开是很好的起点。
I recommend putting StructureMap with the MVC project. I think this logically makes the most sense and having that unused reference in some cases will not be a problem.
I think your current set up (CompanyFramework assembly + MVC assembly) is pretty reasonable. I've found that I end up following that same sort of patter: a common assembly, a web assembly (or specifically targeted to MVC or web forms), a database assembly, etc. Separating them at a high functional level like this is a good place to start.