だから私はWeb サービスを設計しています。Databaseに自動的に書き込むには、このServiceが必要です。これは非常に簡単です。しかし、明らかにSqlはうまく機能しない傾向があります。
これは、トラブルシューティングの際に悪夢を引き起こします。言うまでもなく、Web サービスを使用すると、デバッグがさらに悪夢になります。
そこで、インターネットを調べたところ、スタック オーバーフローに関する記事に出くわしました。この記事では、本質的にこれらの膨大なリストを持つSqlHelper クラスについて説明していました。
public static bool IsDuplicateId(SqlException sex)
{
return (sex.Number == 2601);
}
これらのすべてのMethodsを呼び出す必要があるため、その実装は面倒です。しかし、誰かが次のように答えました:
switch (e.Number)
case 2601:
// Do Something
break;
default:
throw;
そこで、これらの考えられるエラーの大部分を処理するクラスを作成しない理由を考えました。この特定の実装を念頭に置いて:
public class SqlExceptionHelper
{
public SqlExceptionHelper(SqlException sqlException)
{
// Do Nothing.
}
public static string GetSqlDescription(SqlException sqlException)
{
switch (sqlException.Number)
{
case 21:
return "Fatal Error Occurred: Error Code 21.";
case 53:
return "Error in Establishing a Database Connection: 53.";
default
return ("Unexpected Error: " + sqlException.Message.ToString());
}
}
}
したがって、私の思考プロセスは、いくつかの一般的なエラーを検出するために再利用できるクラスがあるということです。他のクラスでは、次のusing SomeNamespace.ExceptionHelpers;
ように簡単に実装できます。
public class SiteHandler : ISiteHandler
{
public string InsertDataToDatabase(Handler siteInfo)
{
try
{
// Open Database Connection, Run Commands, Some additional Checks.
}
catch(SqlException exception)
{
SqlExceptionHelper errorCompare = new SqlExceptionHelper(exception);
return errorCompare.ToString();
}
}
}
したがって、本質的には、これらすべての素敵な例外を処理する必要があります。しかし、私はどれが良くないか考え始めました。 このような例外を返品として返すことは良いことですか? それ自体が悪いのでしょうか?または、これはサービスを介してキャッチするそのような例外を処理するための本当に最良の方法ですか?
したがって、私の質問は次のようになります。
Is this the best way to handle error catching through a Service?
お手伝いありがとう。