例として、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回異なる回数繰り返すと、Don't-Repeat-Yourselfの原則が実際に破られます。また、User
タイプが変更された場合、これらの変更をプロジェクトの異なる部分ごとに繰り返す必要があるという問題もあります。
Googleの protobuf ライブラリは、特別な構文を使用してデータ構造を記述し、ライブラリが複数の異なるプログラミング言語で構造宣言を生成するという、この問題に対する一種のソリューションを提供することを知っています。しかし、これはまだ型の検証ロジックを繰り返す必要があるという問題には対処していません。
これについて本やブログの投稿への提案やリンクはありますか?
そうしない。または、実際には、すべきではありません。
アプリ、サーバー、ウェブサイトを別々のコンテキストとして考える場合、構造が重複していることは理にかなっています。それが良いことである理由:
DRYの原則はすばらしいですが、コンテキストまたはレイヤー間でデータ構造を共有すると、解決するよりも多くの問題が発生します。特に、プロジェクトが大きくなり、さまざまな人々がさまざまなコンテキストで作業している場合。
@Euphoricが、コードを複製しない理由をいくつか挙げました。ただし、そうする必要がある場合は、コード生成を使用することをお勧めします。
これを効果的に行うには、最初にデータの正規形を見つける必要があります。それはあなたのSQLスキーマですか、それともJavaプログラムのクラスですか?
その後、正規のフォームから他のすべてのフォームを生成する方法を考案します。たとえば、正規形式がSQLスキーマであるとすると、JavaScript、Java、およびPythonコードを簡単に生成できます(SQLは簡単に解析され、正規ソースの候補として最適です)。
生成されたコードのセクションを「触らない」としてマークするのは簡単なはずです。これにより、さまざまな表現すべてに必要な違いに対応できます(たとえば、JSフロントエンド用に記述したカスタムコードとJavaバックエンド)再生成後も保持する必要があります。
Gitから例を挙げます。エディターを開いてコミットメッセージを入力できるようにすると、ファイルにはすでにテキストが含まれていますが、# -------- >8 --------
マーカーyourコンテンツの終了位置とits自動生成テキストの開始位置を確認します。
それでも、可能であれば-そのような重複を避けてください。ほとんどのコードが自動的に生成されたとしても、これはPITAです。
この答えは、「ここにいくつかのベストプラクティス」ではなく、ちょっとした話です。私が説明したのは、あなたと同じ問題があり、システムの異なる部分で同じデータを表す必要があるときに、私がかつて行ったことです(または、2つの異なるシステムで)。