language-agnostic - KISSと牛道の舗装について

Question

現在、Access データベースをバックエンドとして使用する PHP アプリケーションを開発しています。あなたが理解している選択ではありません...データベースはクライアントが最初に使用したものであり、それを使用することは要件の一部です。

このデータベースの問題の 1 つは、列名の命名規則が非常に狂っていることです。大文字、小文字、アンダースコア、スペース、そして普通の非常識。たとえば、列「性別」には日付が保持されます。列「User2」も同様です。もっとたくさんありますが、あなたはアイデアを得る.

これに直面して、データベース列を PHP 変数にマップする配列を作成して、コードを狂気から分離できるようにすることにしました。しかし、私の同僚は、私が物事を複雑にしすぎていると考えており、対応する PHP 変数にデータベースの列名を使用する必要があるため、何がどこにあるのかを見つけるためにマッピング配列を調べる必要はありません。

だから私の質問はこれです...私は正しいことをしていますか、それとも物事を複雑にしていますか?

score 22 · Accepted Answer

絶対にあなたは正しい軌道に乗っています。狂気を抽象化しないと、最終的には自分自身が狂気に屈服することになります。

ただし、あなたの同僚は有効な点を持っているので、PHP でデータから列へのマッピングを決定する簡単な方法もコーディングすることをお勧めします。

これは、シンプルに保つことではなく、強固な基盤を改良して構築することです。

私が心配しているのは、この種のランダムなデザインが特定のビジネスルールを隠していることが多いということです。 lubdub... " - 狂ったことは知っていますが、本来よりも一般的です。

score 5 · Accepted Answer

名前は非常に重要です。アプリケーションを保守可能にしたい場合は、コードベースがさらに大きくなる前に修正してください。

score 5 · Accepted Answer

あなたが物事を複雑にしているとは言いません。

Eric Evan の著書Domain Driven Designには、これについて素敵な言葉があります: Anti Corruption Layer

score 3 · Accepted Answer

Devil's Advocate をプレイするには、システムを操作するための短期的なメモリ負荷に不必要な間接層がないようにする必要があります。コードに慣れると、どの変数に何が入っているかがわかります。そのため、主な利点は、コードをゼロから取得する新しい人にとってです。ただし、その問題を適切に修正するには、データベーススキーマも修正する必要があります。これには、(a) かなりの作業量が必要であり、(b) 問題の大部分が解消されます。

この質問に対する白黒の答えはありません。特定の問題に対する明確な答えがないということは、眠っている犬を寝かせたいと思うかもしれないことを示唆しています.

一方、クリーンアップ操作が可能な範囲内にある場合は、リファクタリングタイプベースで実行し、機会が生じたときに DB 列名を段階的に修正することをお勧めします。

score 2 · Accepted Answer

2

最も必要な場所にビューを作成するだけです。

于 2008-11-27T13:08:10.087 に答える

score 1 · Accepted Answer

各テーブルにマップするクラスを使用してデータレイヤーを作成してみませんか。次に、列にアクセスするためのクラスメソッドを定義し、メソッドに任意の名前を付けることができます。次に、データレイヤーデータベースアクセスコードは、実際の列名について知る必要がある唯一のものです。誰か（おそらくいくつかのソネオネ）がこれを行うためのフレームワークをすでに開発しているのではないかと思います。Googleの「phporm」。

score 1 · Accepted Answer

これは、IMHO のコーディングの核心に触れているため、良い質問です。

私はあなたと一緒に行き、悪い名前を読みやすいまともな名前に抽象化します. その結果、より論理的に理解しやすく読みやすいコードを作成するには、少し複雑になります。

score 1 · Accepted Answer

Access で列の名前を変更できないとは言わなかったので、そうしてください! もう 1 つの可能性は、テーブルごとにビューを作成し、ビュー内の列の名前を変更することです。次に、テーブル Employees を操作する代わりに、ビュー vEmployees を操作します。私の記憶が正しければ、Access では、ビューを選択するだけでなく、ビューを更新することもできます。ただし、PHP で ORM を使用している場合は、ビューの更新をサポートしていない可能性があります。

score 1 · Accepted Answer

名前に意味がある場合でも、テーブル名と列名をハードコーディングすることは決して良い考えではありません。

ただし、配列を使用することが最善の解決策であるかどうかはわかりません。私はPHPにあまり詳しくありませんが、テーブル名を格納するために定数文字列のようなものを使用したでしょう。私が使用している言語では、これによりコードが読みやすくなります。

score 1 · Accepted Answer

このデータベースに行き詰まるのは非常に不運ですが、全体として、フィールド名をより賢明なものに抽象化する方法はよりスマートだと思います。

DBからデータを引き出すときに、データベース名、サニタイズされた名前、タイプ、およびコンテンツのフィールドを含むデータ構造を作成するでしょう。これにより、物事をまとめる便利な方法が得られるため、クレイジーな名前スキームをマッピングするだけではありません。

score 1 · Accepted Answer

絶対にあなたは正しいことをしています。私の意見では、そこにいくつかの正気を実装する方が良いでしょう。今後、そのデータベースまたはその列名のいずれかを変更することを決定した場合でも、ロジックが破棄されることはありません。マッピングを正しい方法で構築すれば、新しいテーブル/列をすぐに挿入するのは簡単です。

どちらかといえば、あなたがしていることは、ソリューション全体の俊敏性を向上させます。

もちろん、KISS はあなたのマッピング方法にも当てはまります。

score 1 · Accepted Answer

アプリケーションの最後で適切な列名を使用することが最善の方法です。そして、「そのフィールドは何だったのか」を調べる必要がない限り、それを行う必要があります。他のことをした後でもう一度見なければならないとき。

あなたの同僚のポイントは、物事を過度に複雑にしないことです。それも有効です。

そのため、1 つまたは複数のメソッドでフィールドへのアクセスをカプセル化し、そのメソッドに変換を行わせます。マップを使用すると、これはパフォーマンスの問題にはなりません。

実際、データソースへのすべてのマッピングを 1 つのオブジェクトに配置すると、顧客が実際のデータベースの使用を再考した場合に役立つ可能性があります。そして、顧客は自分の意見を変えるのが大好きです。

score 0 · Accepted Answer

0

ORMを使用してください。すぐにデータベースを変更します...

于 2008-11-27T13:35:39.610 に答える

score 0 · Accepted Answer

データベースを維持する必要があります。私が提案できる 1 つの可能なアプローチは、計画どおりにアプリケーションコードでフィールド名をマップすることです。しかし、遅かれ早かれ、フィールド名を使ったこのネーミングの狂気への対処を開始し、修正する必要があります。問題を選別して、それが安全な解決策であり、進むべき道であると考えるのは得策ではありません。これは一時的な回避策にすぎません。それについてあなた自身をいっぱいにしないでください。

language-agnostic - KISSと牛道の舗装について

14 に答える 14

Related

Reference