3

シナリオ

約20のASP.net（VB）アプリケーションが同じコードフレームワークを共有し、展開されると共通のweb.configも共有します。さまざまなアプリケーション全体で、System.Net.Mail.SmtpClient / MailMessageを使用して電子メールを送信します。次に、既存のコードに最小限の変更を加えて、ユーザーに電子メールのオプトアウト機能を実装します。それは最も単純なアプローチを除外します。SmtpClient（OurSmtpClientなど）からクラスを継承し、Send（）メソッドをオーバーライドして、電子メールを受信しないことを選択したすべてのユーザーを削除します。これは、すべてのNew SmtpClient（）をNew OurSmtpClient（）に変更する必要があることを意味します。アプリ。

代替案

以前、tagMappingを使用してタグを社内の派生代替に再マップしましたが、すべてのSmtpClientが自動的にOurSmtpClientになり、オーバーライドされたSend（）メソッドを使用するように、クラスに類似したものはありますか？

拡張機能についても見てきましたが、ここでの問題は、既存のメソッドをオーバーライドできず、新しいメソッドを追加するだけであるということです。

私たちが検討した次の代替案はリフレクションですが、実際にそれを実装する方法については頭を悩ませることができませんでした。

イベント..ああ、送信イベントがあった場合..。

コード（誰もがそれを好きだから）

これが、私たちが探しているものを理解するための継承アプローチです。

Public Class OurSmtpClient
    Inherits SmtpClient

    Public Overloads Sub Send(message As MailMessage)
        For i As Integer = message.To.Count - 1 To 0 Step -1
            With message.To(i)
                If (.Address.Contains("test")) Then
                    message.To.RemoveAt(i)
                End If
            End With
        Next

        MyBase.Send(message)
    End Sub
End Class

助言がありますか？既存のアプリケーションのコードを変更せずに、共有コード（アプリのApp_Codeに存在する）または共有web.configでのみこれを行うにはどうすればよいですか？

4

2 に答える 2

2

これは、メールクライアントではなくデータレイヤーで変更します。

ユーザーに関するすべての情報を、ユーザーがそれ以上メールを受信したくないという情報とともに、中央のどこかに保存していると想定しています。したがって、私の目には、電子メールを送信するユーザーのリストを要求するたびに、それらのユーザーを単純に返さないようにする可能性があります。

現在のアプリケーションがどのように機能するかについては十分にわかりませんが、それを変更するのに最も便利な場所のようです。

于 2012-09-10T12:23:45.103 に答える
0

単純な要件であるべきものを実装するのに苦労しているという事実は、技術的負債を積み上げすぎているという大きな手がかりです。あなたの投稿は、技術的負債を返済することに強い抵抗を示しています。これは避けなければならないことであり、代わりにMercilessRefactoringを採用する必要があります。弾丸をかみ、その特殊なSMTPクラスを紹介します。

于 2012-09-17T11:57:17.817 に答える