1

データベースクエリの結果を含む配列を使用しています。これは後でhtml（Webアプリケーションの場合）またはcsv（スプレッドシートへのインポートの場合）としてフォーマットされます。この要素のデータの使用方法に関する追加情報を持つ配列要素に情報を添付したいと考えています。

たとえば、配列要素データ...

  • ... リンクとして表示できます: リンク情報を添付してください。配列から html を作成するコードは、それを使用してリンクを作成できます。
  • ... は次の形式の日付です2009-09-14: 次に、何らかの形で日付としてフラグを立てたいと思います。使用法が html ページである場合は、もう少し美しく表示できます (例: Mo Sep 14またはToday )。受信者が csv の場合はそのままにしておくことをお勧めします。

この問題を解決するベストプラクティスの方法はありますか?

私はいくつかの可能な解決策を考えましたが、誰かがすでに「ベストプラクティス」を知っているかどうか尋ねたかった. おそらく最高のものから最悪のものまで：

  1. 配列要素をテキストとして保持する代わりに、各配列要素をカスタム作成オブジェクト (Date、Linkable、Text...) として保存します。おそらくデフォルトの.to_string()メソッドを提供します。
  2. a[5][7]['text']orと言えるように、各配列要素をハッシュにしa[5][7]['link']ます。
  3. 配列の異なるバージョンを作成しますtextArray[5][7]。linkArray[5][7]

最初に html を作成し、テキスト バージョンだけを使用するのは、使用方法によって外観が異なるため (例: 2009-09-14対Mo Sep 14 ) 、悪い考えのように思えます。

それとも、間違った質問をしているだけですか?

4

3 に答える 3

0

Web フレームワークでの一般的なアプローチは、レコードをオブジェクトにマップすることです。データベースからの 1 つのレコードが 1 つのオブジェクトに読み込まれるため、結果はオブジェクトの配列になります。異なるテーブルには、異なるクラスが必要です。これは、多くの Web フレームワークで使用されるモデル ビュー コントローラー (MVC) パターンのビルディング ブロックの 1 つです。

たとえば、Ruby on Rails では、 Tableusersは Class によって処理されUserます。足場を使用して両方を作成します。

ruby script\generate scaffold user lastname:string link:string joined:date

ここでは、Date、Boolean、String、Text、Decimal、Integer が個別のデータ型です。残念ながら URL はそうではないので、リンクには String を使用する必要があります。

次のように、データベースからユーザーを読み取ることができます。

@u = User.find(77)       # gives you one object
@list = User.find(:all)  # gives you an array of User-objects

ユーザー オブジェクトの属性には、日付、数値などを操作するための正しい型があります。

100.days.ago < @u.joined の場合 ....

データ固有のロジックは User クラスに実装されています。

ユーザーのリストは、次のようなビューを使用して HTML で表示できます。

  <h1>Listing Users</h1>
  <table>
    <tr>
      <th>Lastname</th>
      <th>Link</th>
      <th>Joined on</th>
    </tr>
  <% @list.each do |user| %>
    <tr>
      <td><%=h user.lastname %></td>
      <td><%= link_to "Homepage", user.link %></td>
      <td><%=h user.joined %></td>
    </tr>
  <% end %>
  </table>

データの表示に固有のロジックは、ビューに実装されています。オブジェクトのどの属性がリンクまたは通常のテキストとして扱われるかという知識は、オブジェクト自体ではなく、ビューに存在します。

cvs-viewを作成することで、cvsと同じデータの表示・出力を行います。

于 2009-09-14T13:03:10.870 に答える
0

一般的なアドバイスとして、データ自体を表現する方法に関する情報がデータにまったく含まれていないことが最善です。

代わりに、表現を作成するアプリケーションの一部は、これらの設定を別のデータ構造に持つ必要があります。XML ファイルとさまざまな表現を作成するさまざまな XSLT ファイルと考えてください。

しかし、これが不可能な場合、または実際の変換のために 2 つの情報を 1 つのデータ構造にマージする必要がある場合は、次の経験則に従いました。

賢くなりすぎず、あなたの言語で最も自然なことをしてください!

  • Java と Delphi では、コンパイル時のチェックなどの特定の利点があるため、常に「カスタム オブジェクト」バリアントを使用していました。
  • PHP では、より PHP らしいスタイルであるため、常にハッシュを使用しました。

「解決策 3」は時々やったことがありますが、いつも後悔していました。これらの構造はメンテナンスの悪夢になる傾向があり、データの観点からもコーディングの観点からも、同期の問題に遭遇する可能性が最も高くなります。

于 2009-09-14T12:44:32.457 に答える
0

言語を指定しない限り、(1) と (2) は基本的に同じです。オブジェクトまたはハッシュ、おそらく構文以外の動的プログラミング言語の違いは何ですか? Lua ではすべてが辞書です。

(1)/(2) は通常、(3) よりも優先されます。これは、一般に、要素とそのメタデータのコピーがはるかに簡単になるためです。たとえば、ソートするとき。

したがって、言語/環境に固有のものではなく、特別な条件がない場合のベスト プラクティスは、何らかの方法でメタデータと要素を結合し、結果のデータ型を処理することです。これを行うには、両方を含む新しいクラスを定義するか、元の要素型のサブクラスをもう 1 つ定義するか、ジェネリック ペアを使用するか、汎用ディクショナリを使用するか、元のオブジェクトにメタデータを格納するだけです (これにより、たとえば、Javascript では明らかなアプローチです)。

于 2009-09-14T12:41:02.350 に答える