常见的扩展方法属于项目的哪一层？
我很好奇应用程序全局的系统通用扩展属于哪个“层”。例如，我可能有一些扩展，可以让我使用类似 Rails 的“DaysAgo”、“MonthsAgo”等类型的扩展整数方法。这通常属于项目的哪一层？我在想基础设施，但这似乎意味着与数据库相关（例如基础存储库和数据访问）。我有一个“核心”库项目，所以它可能属于那里？
我知道您想要对与特定类组相关的扩展进行分组，但这些扩展本质上是在整个应用程序中使用的。在扩展方法出现之前，它们将位于 Utilities 静态类或类似类中，那么它们现在应该位于哪里呢？
I'm curious what "layer" of a system common extensions that are global to the application belong in. For instance, I may have extensions that let me use the Rails-like "DaysAgo", "MonthsAgo", etc. type of extension method on integers. What layer of a project does this typically belong in? I was thinking Infrastructure, but that seems to mean database-related (e.g. base repositories and data access). I have a "Core" library project, so maybe it belongs there?
I understand that you want to group extensions that are related to a specific group of classes, but these are essentially used across the entire application. In the days before extension methods, they would be in a Utilities static class or the like, so where should they live now?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以（更好）根据范围创建多个基础设施项目，例如：
Infrastructure.Common（这里是通用基础设施 - 最适合扩展方法）
基础设施.数据（数据访问）
基础设施。布拉布拉布拉
You can (better) create multiple infrastructure projects based on scope for example:
Infrastructure.Common (here comes the general infrastructure - best fit for extension methods)
Infrastructure.Data (Data access)
Infrastrcuture. bla bla bla
我会将这些方法放在这些对象/实体存在的尽可能最低的层。
无论是在接口、实体还是核心组件中，越低越好，以便所有上层都可以使用它:)
I would put these methods at the lowest possible layer where those objects/entities exist.
either in the interfaces, or in the entities or in a core assembly, the lowest the better so all upper layers can use it :)
我会将它们放入一个从所有其他项目引用的基础项目（如“核心”）中。如果您一段时间开始一个新项目，您可以轻松地重用这些扩展方法。
我会考虑您将用于不同的扩展方法集的名称空间。如果某些确实属于 Data，只需将它们放入 Core.Data 命名空间中，这样其他项目中的代码就不会因在该上下文中没有意义的扩展方法而混乱。
I would put them in a base project (something like 'Core') that is referenced from all other projects. If you start a new project in some time you can reuse these extension methods easily.
I would think about the namespaces you will use for your different sets of extension methods. If some really belong to Data, just put them in a Core.Data namespace so your code in other projects won't be cluttered with extension methods that have no meaning in that context.
考虑将整个应用程序范围之外的逻辑放入其自己的程序集中。
Consider putting logic that is outside the scope of the entire application in its own assembly or assemblies.