アプリの一部が異なる言語で記述されている場合、データ構造の重複を回避するにはどうすればよいですか?


12

例として、Javaでアプリを書いているとしましょう。

アプリは、Pythonで記述されたAPIサーバーと通信します。

PythonサーバーはSQLデータベースと通信します。

JavaScriptで記述されたアプリのWebサイトもあります

4つの異なる言語を使用すると、本質的に同じデータ構造を4回異なるものにするのは簡単です。

たとえば、User型は次のようになります(擬似コード):

type User {
  integer id;
  string name;
  timestamp birthday;
}

プロジェクトのすべての部分には何らかの表現が必要でしょうUser。JavaパーツとPythonパーツには、2つの異なるclass宣言が必要です。データベースにはUserテーブル宣言が必要です。そして、フロントエンドサイトUserも代表する必要があります。

このタイプを4回繰り返すことは、「繰り返しはしない」という原則に反します。また、Userタイプが変更された場合、プロジェクトのさまざまな部分でこれらの変更を繰り返す必要があるという問題があります。

Googleのprotobufライブラリは、特殊な構文を使用してデータ構造を記述し、ライブラリが複数の異なるプログラミング言語で構造宣言を生成するというこの問題に対する一種のソリューションを提供することを知っています。しかし、これでも型の検証ロジックを繰り返さなければならないという問題には対応していません。

これに関する本やブログの投稿への提案やリンクはありますか?


これが、多くの人々がすべての開発をJavaScriptに移行している理由の1つです。クライアント(Web、モバイル用ionic、デスクトップ用electro)、サーバー(ノード)、データベース(MongoDB)上で動作します。
ポール

3
バックエンドとフロントエンドが同じ言語を使用している場合、同じデータ構造を共有できます。異なるコードベースを使用している場合は、繰り返さないでください。ツールを使用して、さまざまな開発プラットフォームからxmlスキーマまたはJson文字列からクラスを生成します。
ジョンレイナー

5
Repeating this type 4 different times really breaks the Don't-Repeat-Yourself principle。ありません。異なることを行う4つの異なるシステムがあります。乾燥しすぎています。私の経験では、やりたいと思う再利用性は悪の種です。なぜなら、密結合を導入するからです。それUserは、4つの異なる言語で4回繰り返したよりもさらに悪いことです。分散環境では、カップリングが問題です。DRYではありません。
ライヴ

答える時間がない:ニーズに応じて、OWLなどを使用して検証のルールを策定することができます(オントロジーを構築します)。検証ルールは、必要な時点で使用できる「データ」になります。ルールの変更は、1つの中央の場所で実行できます。
ダニエルジュール

回答:


12

あなたはそうしない。または実際には、すべきではありません。

アプリ、サーバー、Webサイトを別々のコンテキストと考える場合、構造が重複していることは理にかなっています。それが良いことになる理由:

  • 構造は似ていますが、同じではありません。たとえ構造の90%がすべてのコンテキストで同じであっても。その10%があなたに大きな頭痛を与えます。
  • パターンと実装は異なる場合があります。異なる言語とフレームワークが使用されている場合、すべての言語とフレームワークで同じ実装を行うことは非常に困難になります
  • 共有構造は依存関係になるため、管理する必要があります。依存関係を共有すると開発が非常に複雑になります。あるコンテキストでは大きな変化が別のコンテキストではひどいためです。そのため、この共有依存関係の開発を調整するには多くの努力が必要です。
  • 異なるコンテキストには異なる展開があります。すべてのコンテキストで同じデータ構造と同じ検証コードを共有できたとしても、1つのコンテキストの新しいバージョンがデプロイされている間に他のコンテキストが古いバージョンにデプロイされている場合があります。対処される

DRYの原則は驚くべきものですが、コンテキストやレイヤー間でデータ構造を共有すると、解決するよりも多くの問題が発生すると思います。特に、プロジェクトが大きくなり、さまざまな人がさまざまなコンテキストで作業している場合。


5

@Euphoricには、コードを複製しない2つの理由がリストされていると思います。ただし、必要な場合は、コード生成を使用することをお勧めします。

データの正規形を見つける

これを効果的に行うには、最初にデータの標準形式が何であるかを発見する必要があります。SQLスキーマですか、それともJavaプログラムのクラスですか?

それから他のフォームを(自動的に)引き出す

その後、標準形式から他のすべての形式を生成する方法を考案します。たとえば、標準形式がSQLスキーマであると仮定すると、JavaScript、Java、およびPythonコードをそこから簡単に生成できます(SQLは簡単に解析され、標準ソースの適切な候補です)。

違いに対応する

生成されたコードのセクションを「触れない」としてマークするのは簡単です-このようにして、すべての異なる表現(たとえば、JSフロントエンドとJavaバックエンド用に作成したカスタムコード)の必要な違いに対応します再生後も保存する必要があります。
Gitの例をご覧ください。エディターを開いてコミットメッセージを入力できるようにすると、ファイルには既にテキストが含まれています# -------- >8 --------コンテンツの終了位置自動生成されたテキストの開始位置を知るためのマーカーがあります

それでも、可能であれば-そのような重複を避けてください。ほとんどのコードが自動的に生成される場合でも、これはPITAです。


この答えは、「ここにいくつかのベストプラクティスがあります」ではなく、ちょっとした話の時間です-私が説明したのは、あなたと同じ問題があり、システムの異なる部分に同じデータを表示する必要があるときに私が一度やったことです(または、むしろ、2つの異なるシステムで)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.