ASP.NET WebForms - обработка специальных параметров строки запроса на всех страницах сайта - перезапись URL, маршрутизация URL или другие подходы?

Question

Работа на сайте электронной коммерции, который будет интегрирован со сторонним поставщиком - этот поставщик использует другие идентификаторы для магазинов, чем мы используем для себя (т.е. их магазин ABC123 - это наш 001-321).

I 'm изучает лучший подход для проверки входящих запросов на наличие зарезервированных параметров строки запроса, которые указывают, что запрос использует их идентификаторы, и сопоставляют идентификаторы с нашими идентификаторами (поэтому, если запрос - example.com/&theirId=ABC123Я хочу преобразовать запрос в example.com/&ourId=001-321).

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

Пока я исследую несколько различныхподходы:

• Реализация его на базовой странице (которая уже делает слишком много, нокак преимущество нашей инфраструктуры ведения журналов и некоторых других внедренных зависимостей)
• Реализация его в IHttpModule
• Использование перезаписи URL
• Использование маршрутизации URL (похоже, что маршрутизация - это не то, чего я хочу, не стесняйтесь предлагать информацию, если вы думаете, что она по-прежнему подходит)

Стоимость производительности является соображением: фактическое количество раз этот перевод будетпроизойдет очень мало по сравнению с количеством запросов , а не , требующих его - возможно, 1%.

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

Answer 1

Это классический случай, когда модуль HTTP имеет наибольшее значение - вы хотите погрузиться в обработку URL-адресов по всем запросам.Сверхурочно, у вас не должно быть особых проблем, если предположить, что вы можете правильно замкнуть накоротко и избежать поиска в БД / кеше там, где он вам не нужен.

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

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

Answer 2

Я обычно создаю класс Singleton для хранения контекста запроса сайта и храню его в HttpContext.Current.Items (). Я инициализирую этот класс в подпрограмме Application_BeginRequest.

Imports System.Web

Открытый класс SiteContext

Private _viewId As Int32 
Private _tab As String
Private _action As String

Private Sub New()
    _viewId = -1
    _tab = String.Empty
    _action = String.Empty

    FillContext()
End Sub

Public Shared Function Instance() As SiteContext
' gets the site specific context for the current request

    If HttpContext.Current.Items("RequestContext") Is Nothing Then
        HttpContext.Current.Items("RequestContext") = New SiteContext
    End If
    Return HttpContext.Current.Items("RequestContext")

End Function

' fill the request context with site specific items
Private Sub FillContext()

    ' iterate through all items passes via the querystring and save values to matching key property names
    For i As Int16 = 0 To _context.Request.QueryString.Count - 1
        Dim qryItem As String = _context.Request.QueryString.Keys.Item(i)

        Select Case qryItem
            Case "v", "view", "viewid", "vid" ' VIEW ID
                If IsNumeric(_context.Request.QueryString(qryItem)) AndAlso CType(_context.Request.QueryString(qryItem), Double) < 10000 Then
                    _viewId = CType(_context.Request.QueryString(qryItem), Int32)
                End If

            Case "tab" ' TAB ID; secondary parameter to choose sub view
                _tab = _context.Request.QueryString(qryItem)

            Case "action" ' ACTION ID; tertiary parameter to choose sub-sub view
                _action = _context.Request.QueryString(qryItem)

            Case Else

        End Select
    Next

End Sub

Public Property ViewId() As Int32
    Get
        Return _viewId
    End Get
    Set(ByVal Value As Int32)
        If Value < 1 Then
            Value = 1
        End If
        _viewId = Value
    End Set
End Property

Public Property Tab() As String
    Get
        Return _tab
    End Get
    Set(ByVal Value As String)
        _tab = Value.Trim
    End Set
End Property

Public Property Action() As String
    Get
        Return _action
    End Get
    Set(ByVal Value As String)
        _action = Value.Trim
    End Set
End Property

Конечный класс

Answer 3

Я реализовал нечто похожее на это в качестве класса базовой страницы для моих страниц aspx, но, как вы упомянули, модуль также будет работать. По моему мнению, если бы эта функциональность была необходима на всех страницах, я бы просто создал базовый класс только потому, что поддержка другого http-модуля более трудна, потому что он должен отображаться в вашем веб-config / iis. Перезапись URL-адресов требует значительных ресурсов процессора и может не дать вам необходимой гибкости - опять же, она просто добавляет другую зависимость конфигурации / iss. Я не думаю, что что-то из этого может повлечь за собой большие накладные расходы, если вы внедрите какое-то кэширование.

Надеюсь, это поможет ...

Наслаждайтесь!