Где вы размещаете методы для общих веб-путей

Question

У нас довольно распространенная архитектура:

База данных

Слой репозитория

Бизнес-объекты

Сервисный уровень - обслуживает DTO для клиента

Веб-слой (MVC)

У нас есть несколько общих путей к ресурсам, в частности изображениям и подкастам (например, http://media.mysite.com/podcasts/). Я хочу создать статический служебный класс со свойствами:

MySite.Utils.ImagePathUri

MySite.Utils.PodcastsPathUri

и т.д. * * тысяча двадцать-одна

Мой вопрос: куда вы кладете пути Ури? В какой проект входит этот служебный класс?

Первоначально это казалось легким делом: веб-слой. Это веб-сайт. Я должен иметь возможность изменять URL-адреса сайта, чтобы другие слои не знали об этом.

Все было хорошо, но. , , затем однажды одна из моих служб должна была предоставить тип SyndicationFeed. SyndicationFeed нужен полный URI, а не только частичное имя файла. Но сервисы не должны иметь доступа к полным путям. Или они должны?

Я обсуждал с собой несколько вещей, но не могу придумать твердую позицию:

1. Переместите пути на уровень сервисов. Это тесно связывает веб-слой со слоем сервисов, но, возможно, это нормально, поскольку они довольно тесно связаны с самого начала.
2. Перемещение путей к бизнес-объектам или репозиториям. Мне это не нравится, но если я открыт для того, чтобы поместить его на уровень сервисов, я должен хотя бы рассмотреть это.
3. Не используйте SyndicationFeed внутри уровня сервисов, но используйте его только в веб-слое. Решает проблему, но кажется, что SyndicationFeed должен принадлежать к уровню служб.
4. Отменить подачу SyndicationFeed. Любой SyndicationFeed легче создать в MVC с помощью PartialView, который генерирует соответствующий XML без необходимости возиться с раздутыми абстракциями, такими как ElementExtensions. Мне нравится этот, но мы используем SyndicationFeed во многих местах, так что вам потребуется больше объяснений.
5. Предоставьте поддельный URI для канала синдикации в слое служб, а затем измените его в веб-слое. Вы можете сказать, взломать?
6. Положите полный путь в базу данных. Сначала это звучит нормально, но потом я понимаю, что оно ломается, как только у вас появляется динамически сгенерированное изображение.
7. Другое решение, которое мне не приходит в голову.

Что ты думаешь? Где вы размещаете служебные классы для веб-ресурсов (изображения, подкасты и т. Д.)? И если вы скажете «веб-слой», как вы относитесь к проблеме SyndicationFeed?

UPDATE

В конце дня я решил отказаться от класса SyndicationFeed, что исключило необходимость включения пути к файлу в слоях обслуживания и хранилища. Однако проблема все еще возникает в другом месте, и использование DI и, в частности, IoC, такого как Ninject, имеет смысл. Так же как и их объединение в общий интерфейс.

SyndicationFeed, Просмотр движков и почему Декларативный делает Декларативный лучше

Я отказался от SyndicationFeed и вместо этого создал XML, который мне нужен, с помощью Razor. Это не только намного проще в создании, но и на 1000% более читабельным. Я пришел к выводу, что использовать императивный код (C #, VB и т. Д.) Для создания XML просто сложнее, чем следовало бы. XML декларативный, а не обязательный.

Вместо этого я решил, что с декларативным синтаксисом View Engines (например, Razor) работать намного проще, чем с императивными языками.

Answer 1

Столкнувшись с подобной ситуацией, я чувствовал, что лучший способ приблизиться к этому - это определить интерфейс конфигурации, который привел бы к объекту на самом верхнем уровне. Каждый промежуточный слой улучшит интерфейс с более конкретными свойствами и операциями:

public interface IWebConfiguration 
{
    string RootImageUri { get; }
}

сервис будет добавлять слой, который сам добавит необходимые вещи:

public interface IServicesConfiguration
{
    string SyndicationFeedUri { get; }
}

public interface IDatabaseConfiguration
{
    string ConnectionString { get; }
}

В конце концов, я заставил веб-уровень реализовать конкретный объект, который связал все интерфейсы. Гадкий? Может быть. Я признаю, что там были звонки isa и некоторые актеры.

Однако я смог передать каждому слою строго типизированный интерфейс. На мой взгляд, это было бы лучше, чем серия вызовов, чтобы получить старую строку из файла конфигурации. Кроме того, поскольку каждое свойство было определенным для слоя, а агрегатный объект передавался, мне пришлось загружать конфигурацию только один раз.

Answer 2

Я чувствую твою боль. У меня тоже была похожая ситуация, которую я разрешил, передав URI в мой слой хранилища, из моего веб-слоя.

Мой проект использует Ninject для привязки, и, поскольку я уже передавал строку подключения в хранилище с помощью Ninject, было также просто передать мою строку пути.

Мой репозиторий затем массирует строку пути и заполняет необходимые свойства в моем бизнес-объекте.

Это правильно? Я не знаю, но это работает на данный момент. Я не совсем доволен решением, но у меня еще не было возможности попытаться улучшить.

Хотелось бы услышать, как другие справились с этим.