0

サイトが大好きです。私の研究を通して非常に有益でした。C# 入門の四半期が終わったばかりで、プロジェクトの 1 つは、残高を保持し、引き出しと預金が行われたときにそれを更新する金融 "アカウント マネージャー" アプリを設計することでした。プロジェクトはかなり単純で、何の問題もありませんでした。残念ながら、私の次の四半期にはプログラミングのクラスが含まれていません :( ので、時間を使って、アカウント マネージャー アプリを強化して知識を広げています。

最初にやりたかったことは、複数のユーザーを有効にすることでした。これまでのところ、ユーザー名の重複を禁止し、特定のフォーマット要件について新しいパスワードをチェックし、それをソルトしてハッシュし、それをユーザー名 (電子メール アドレス) と自動インクリメントと共に「アカウント」テーブルに保存する CreateNewUser クラスを含めました。ユーザーID。十分に単純です。

だから今、私は立ち往生しています.何がベストプラクティスなのかわかりません. ユーザーが他のユーザーと同じテーブルを使用するべきではないと思うので、各ユーザーが独自のテーブルを持つべきだと考えています。私は「偏執的すぎる」のでしょうか、それとも一般的なプログラミングのセキュリティ慣行に沿って考えているのでしょうか? 真実は、おそらく誰もこのアプリを使用しないということですが、私は大人になったときに現実の世界で何が適用できるかを学ぼうとしています.

同じテーブルを使用するには、一致するユーザー ID のクエリを使用して DataSet をロードするだけでよいため、大したことではありません。別のテーブルを使用する必要がある場合は、新しいユーザーが作成されたときに動的に新しいテーブルを作成する必要があります。実際のアカウント番号をシミュレートするユーザー ID でテーブルに名前を付けるだけでした。仮定しています。

とにかく、これをカバーする別の質問が見つからなかったので、あなたの考えを聞いてみようと思いました.

ありがとう、

デッドディ

4

2 に答える 2

0

このように考えてください。たとえば、ノートブックを使用して、これらのテーブルの物理的な例を保持する場合。参照できる小さなノートブックをたくさん持っているのか、それとも大きなノートブックを1つ持っているのでしょうか。

正しいデータ（この場合は一致するuserID）のみをプルするようにコードが記述されている限り、すべてのコードがデータへのアクセス許可を処理するため、セキュリティ面で大きな問題はありません。また、データベースとコードにも適切な権限が設定されています。

于 2012-06-16T04:49:05.357 に答える
0

これまでのところ、ユーザー名の重複を禁止し、特定のフォーマット要件について新しいパスワードをチェックし、それをソルトしてハッシュし、それをユーザー名 (電子メール アドレス) と自動インクリメントと共に「アカウント」テーブルに保存する CreateNewUser クラスを含めました。ユーザーID。十分に単純です。

もうダメ。これは Users テーブルである必要があります。財務情報を扱うアプリケーションのアカウントには、非常に具体的な財務上の意味があり、ユーザーごとに複数のアカウントやユーザーが共有するアカウントが必要になる場合があります。

また、Powershell CmdLets (コマンドごとに 1 つのクラスがパターン) を記述しない限り、CreateNewUser クラスは外出して車を燃やすのと同じくらい悪いものです。ユーザーはクラスであり、ある種のリポジトリは問題ありませんが、CREATE NEW はどちらかといえばクラスの関数です。それは間違いなく完全なクラスではありません。クラス内のすべてのメソッドを有効にすると、オブジェクト指向の概念が完全に台無しになります。

ユーザーが他のユーザーと同じテーブルを使用するべきではないと思いますが、

再び完全な初心者の間違い。なぜだめですか？必要に応じて、アカウントおよび/またはユーザーを参照する適切なフィールドに入れれば問題ありません。

次に、新しいユーザーが作成されたときに新しいテーブルを動的に作成する必要があります。

ここで何をしているのか考えたことはありますか？すべての変更を維持管理するということは、存在するユーザーテーブルを見つけてそれらを変更するプログラムを書くことを意味します。窓の外のツーリング サポート。そのように書かれたアプリケーションを見たことがあります - 請求書管理。プログラマーがデータベースが何であるかを理解していなかったため、請求書ごとに 1 つの請求書詳細テーブル (および請求書番号でコード化された請求書ごとの請求書テーブル) がありました。

私は「偏執的すぎる」のでしょうか、それとも一般的なプログラミングのセキュリティ慣行に沿って考えているのでしょうか?

彼らは「あなたは解雇され、データベースがどのように機能するかを学ぶ」という方針に沿っています。

同じテーブルを使用するには、一致するユーザー ID のクエリで DataSet をロードするだけで済みます

;) では、DataSet はまだ存在しますか? Microsoft での過去 30 年間の最悪の慣行に従って、考古学のプログラミングを行う理由はありますか? Microsoft が以前から提供している ORM (Linq2SQL、Entity Framework) を使用する代わりに、アプリケーションを大幅に作成します - ああ -もっと - ああ - オブジェクト指向？

まともな本を読むことをお勧めしますか？Scott Ambler の「Building Object Applications That Work」を調べてみませんか? いいえ、C# 用に作成されたものではありません。興味深いことに、優れたアーキテクチャの概念は 99% 言語に依存しません。

于 2012-06-16T05:43:54.953 に答える