2016-10-26 4 views
0

Java/LinuxバックエンドとC#.NET GUI/Windowsアプリケーションで実行する必要がある複雑な検証ロジックがあり、DRYになりたいです。 ロジックはサーバー部分のwebmethod経由でアクセス可能ですが、ユーザーがデータを変更するたびに検証が実行されるため、webmethodを繰り返し呼び出すだけでは十分ではありません。この問題を解決する方法は何ですか?それは可能ですか?クライアントとサーバー間のコード再利用を実現する方法

私は現在、スクリプト言語を使用していません。可能であれば、任意の言語をソリューションに追加しないようにしたいと思います。

現在、私は約行くには、次の方法を検討している:

  • それは言語のいずれかでロジックを記述して、コンパイル時に別の言語にソースファイルを変換することが可能なはずです。これはおそらく特定のインタフェースを実装するクラスになりますが、using/importはどうなりますか?
  • アンマネージド.dllを作成し、LinuxとWindows用にコンパイルし、JNI/PInvokeを使用してメソッドを呼び出すことは可能ですが、異なるプラットフォーム用のアンマネージド.dllを作成するのに十分な能力はありません。おそらくCまたはC++になる可能性があります。これは私が控えたい(新しい言語を追加する)ものです。
  • お願いします。

    +0

    ある種のスクリプト言語/カスタムdslを使用することをお勧めします。これは、ある言語から別の言語への変換やネイティブコードの共有を必要としません。おそらく、そこにはかなりの数のライブラリがあります。必要なものを提供します:検証ロジックを記述するDSLと、JavaとC#のAPIバインディングを提供するエンジンを実行するエンジンです。私の頭に浮かぶ言語は、ECMA Script/JavaScriptです。 – Thomas

    答えて

    -1

    私が行うこと:検証に適用する制約を記述し、そのためのパーサを実装し、インメモリモデルで記述ファイルを読み込み、モデルに基づいたソースコードジェネレータを実装するように設計します(declarative language)。

    あなたはJSON形式のテキストとしてそれらの制限を記述することができると思う場合は、次のことができます。

    1. 設計ステップ1のため、最大でJSON schema - あなたはそれ以外の場合は、絶対に杓子定規になりたい場合にのみ、このJSON構造の簡単な説明/仕様で十分です。
    2. パーサーの実装をスキップし、既にJSON->プレーンオブジェクトバインディングライブラリ(Javaの世界では、gsonが心に浮かぶ)を使用してください。インメモリモデルは、ポイント1の仕様として非常によく機能するかもしれません。

    (再度、Javaの世界では、私はApache's Velocityとの良好な経験を持っていた)、メモリ内のモデルから言語固有のソースを生成するtemplatingパッケージを使用しかし、その後、再び、それは私の好みのようになります。私は似ていました最近の過去3〜4回のことで、私はこのアプローチを大いに感じています(そして、「ソースコード生成」の欠点を認識しています - 主なもの:生成されたコードのカスタマイズが必要な場合、次世代で上書きされる危険性があります。コードをクラスとして生成し、それを基に行動をカスタマイズします。

    +0

    ありがとうございました。 Velocityは良い選択肢であり、.NET用のポートもあります。 「大規模な」アプローチのための追加の賞。 – meriarith

    +0

    @meriarithええ、まあ...私はJavaCCパーサーでもやったことがあります.JSONのアプローチは、あまりにも冗長な「仕様言語」をもたらしました。内部のさまざまなアーティファクト間の関係に従うのは難しいです。テクニックとしてうまく機能し、実装は十分に速くなります(言い換えれば、最初の2〜3つの経験は難しいです:))。 –

    0

    クライアント側の検証は、データ操作の結果として最小限に抑える必要があります。同じライブラリクライアントとサーバーを使用することは、クライアントdllがリバースエンジニアリングされている場合、サーバー側が理解されることを意味します。

    検証が最小(番号フィールドに文字がない)でデータが正しいと見なされ、サーバーが検証してクライアントに通知してデータを元に戻すことができないようにすることが推奨されます。

    関連する問題