常见 Web URI 路径的方法放在哪里

Question

我们有一个非常常见的架构：

数据库

存储库层

业务对象

服务层 - 为客户端

Web 层 (MVC)

提供 DTO我们有许多通用的资源路径，特别是图像和播客（例如 http://media.mysite.com/podcasts/）。我想创建一个具有以下属性的静态实用程序类：

MySite.Utils.ImagePathUri

MySite.Utils.PodcastsPathUri

等

我的问题是：您将 uri 路径放在哪里？这个实用程序类进入哪个项目？

最初，它似乎是理所当然的：Web 层。这是一个网站。我应该能够在其他层不知道的情况下更改站点的 URL。

一切都很好，但是，。 。 。然后有一天，我的一项服务需要提供 SyndicateFeed 类型。 SyndicateFeed 需要完整的 URI，而不仅仅是部分文件名。但服务不应该访问完整路径。或者他们应该？

我与自己争论了几件事，但无法得出坚定的立场：

1. 将路径移至服务层。这将 Web 层与服务层紧密耦合，但也许没关系，因为它们一开始就非常紧密耦合。
2. 将路径移动到业务对象或存储库。我不喜欢这样，但如果我愿意将其放入服务层，我至少必须考虑它。
3. 不要在服务层内部使用 SyndicateFeed，而仅在 Web 层中使用它。解决了这个问题，但 SyndicateFeed 似乎应该属于服务层。
4. 放弃 SyndicateFeed。任何 SyndicateFeed 都可以通过 PartialView 在 MVC 中更轻松地创建，该 PartialView 可以生成适当的 XML，而不必弄乱 ElementExtensions 等臃肿的抽象。我喜欢这个，但我们在很多地方都使用 SyndicateFeed，因此需要最详细的解释。
5. 向服务层中的聚合提要提供一个假 uri，然后在 Web 层中更改它。你能说黑客吗？
6. 将完整路径放入数据库中。起初听起来不错，但后来我意识到，一旦你有了动态生成的图像，它就会崩溃。
7. 我没有想到其他一些解决方案。

你有什么想法？将 Web 资源（图像、播客等）的实用程序类放在哪里？如果您说“Web 层”，您对 SyndicatedFeed 问题有何看法？

更新

最终，我决定废弃 SyndicateFeed 类，这样就无需在服务层和存储库层中包含文件路径。然而，问题仍然出现在其他地方，使用 DI，特别是像 Ninject 这样的 IoC 是非常有意义的。将它们封装到一个通用接口中也是如此。

SyndicateFeed、视图引擎以及为什么 Declarative 比 Declarative 更好

我放弃了 SyndicateFeed，而是使用 Razor 创建了我需要的 XML。它不仅更容易创建，而且可读性提高 1000%。我的观点是，使用命令式代码（C#、VB 等）来创建 XML 比应有的要困难。 XML 是声明性的，而不是命令性的。

相反，我现在认为视图引擎（例如 Razor）的声明性语法比命令式语言更容易使用。

Answer 1

我感受到你的痛苦。我也遇到过类似的情况，我通过将 uri 从 Web 层传递到我的存储库层来解决。

我的项目使用 Ninject 进行绑定，并且由于我已经使用 Ninject 将连接字符串传递到存储库，因此传递路径字符串也很简单。

然后，我的存储库会处理路径字符串并在我的业务对象中填充必要的属性。

这合适吗？我不知道，但目前有效。我对这个解决方案并不完全满意，但我还没有机会尝试改进。

很想听听其他人是如何处理这个问题的。

Answer 2

面对类似的情况，我觉得最好的解决方法是定义一个配置接口，在最顶层生成一个对象。中间的每一层都会使用更具体的属性和操作来完善接口：

public interface IWebConfiguration 
{
    string RootImageUri { get; }
}

服务层将添加其自身所需的内容：

public interface IServicesConfiguration
{
    string SyndicationFeedUri { get; }
}

public interface IDatabaseConfiguration
{
    string ConnectionString { get; }
}

最后，我让 Web 层实现连接所有接口的特定对象。丑陋的？也许。我承认那里有对isa的电话和一些选角。

然而，我能够向每一层传递一个强类型接口。在我看来，这比通过一系列调用从配置文件中获取普通的旧字符串要好。另外，因为每个属性都特定于一个层，并且聚合对象正在传递，所以我只需加载配置一次。