著者トーマス・ハンセン
DRYは、これらの重要なソフトウェアアーキテクチャの省略形の一つです。それは「自分自身を繰り返してはいけない」と古いプロジェクトの任意のユーザのソースコードは、重要な原則を示して維持することを意味します。それはあなたがコードの中で自分自身を繰り返している場合、あなたはすべてのバグ修正や機能のアップデートは、あなたの修正を繰り返すことになりますでしょう、です。
コードの重複は、プロジェクトの保守性を低減し、変更がより困難になって適用されます。以上繰り返し、より混沌とした結果のコード。重複を避けるために、一方、最終的に維持し、バグのプロジェクトを修復することが容易になり、あなたは幸せに、より効率的なソフトウェア開発者となります。要するに、書き込みDRYコードは良いコードを作成することができます。
思考のDRYの方法で、これは新たなレベルへのアーキテクチャの重要な原則できたら、レベルに、あなたは最初からプロジェクト奇跡的な成長、と言っても過言を感じるだろう、任意の注意を払う必要はありません。関数を作成します。未経験のために、コードが空中から現れる「スーパードライ」のメカニズムであると思われます。良いコードはほとんど常に非常に小さいですが、優れたコードは小さいです。
この記事では、私は魔法のスーパードライの開発を紹介だけでなく、私が長年にわたって使用技術のいくつか、彼らはあなたが簡単にASP.NETコアのWeb APIを作成することができます。この記事の全内容は、ユニバーサルソリューションとDRYコードの概念に基づいており、唯一の我々の業界のベストプラクティスを使用しています。しかし、最初に、いくつかの背景理論。
CRUD、HTTP REST和SQL
作成、読み取り、更新、削除（CRUD）は、データモデルのほとんどの行動の基本です。ほとんどの場合、データエンティティタイプは、4つの操作を必要とし、実際には、HTTPおよびSQLは、それらの周囲に発生しています。HTTP POSTは、HTTPを更新プロジェクトのためのプロジェクト、HTTP PUTを読み取るためのプロジェクト、HTTP GETを作成する項目を削除するために削除するために使用されます。また、挿入、選択、更新、削除など、SQL CRUD開発、周り。このいくつかの考えたら、あなたは「すべてのアウトを行く」こととCQRSアーキテクチャを実現するためにしたくないと仮定すると、それは基本的にすべてのCRUD程度であることがわかります。
このように、あなたは言語HTTP動詞を議論するために必要なメカニズムを持って、彼らはHTTP層を介してクライアントからリレーショナルデータベースにC＃のコードを広めることができます。さて、あなたが必要とするすべての層でこれらのアイデアを実装するための一般的な方法です。そして、あなたは優れたアーキテクチャ基盤を通じて自己反復せずにこれを行うことを願っています。ここでは、始めます。
まず、ダウンロードコードをgithub.com/polterguy/magic/releases。Visual Studioでのファイルのオープンmagic.sln解凍。5つのHTTP RESTエンドポイントがで闊歩UIに既に存在していることデバッガを起動し、ノート。どこでこれらのHTTPエンドポイントから？この質問への答えはあなたを驚かせる可能性があるため、コードでの外観をしてみましょう。
あなたは、何のコードを参照してくださいません！
あなたはコードを閲覧し、最初の通知ASP.NETコアWebプロジェクト自体起動すると、実際に空です。これは、あなたが動的にコントローラを含むことを可能にするASP.NETのコア機能で、原因の可能性があります。あなたがその背後にある内部メカニズムを理解したい場合は、Startup.csファイルを表示することができます。一般的には、動的に各コントローラアプリケーションドメインに追加されたすべてのプログラムフォルダの濃度です。あなたは、コントローラと溶液の調製に考えるモジュラー方法を再利用できるように、このシンプルなアイデア。複数のプロジェクトで再利用する能力は、スーパーコントローラDRYの実務になるための最初のステップです。
[開くウェブ/コントローラ/ magic.todo.web.controller、とはTodoController.csファイルを表示します。あなたはそれが空であることがわかります。どこからこれらの5つのHTTP RESTエンドポイントは、そう？その答えは、オブジェクト指向プログラミング（OOP）とC＃ジェネリックメカニズムによるものです。CrudController、配信モデルとビューのデータベースモデルからTodoControllerクラス継承。加えて、それはまた、ITodoServiceインスタンスを作成するために、依存性注入を使用し、CrudController基本クラスに引き渡さ。
ITodoServiceインタフェースはICrudServiceから正しいジェネリッククラスを継承しているため、CrudController基本クラスは、サービスのインスタンスを受け入れるように幸せになりますようにします。さらに、この時点でそれはもちろんのような単純なICrudService、あたかもICrudServiceがジェネリックインターフェイス型である適切なパラメータとを用いる多形サービスでなければなりません。このサービスは、CrudControllerが定義されている5つの共通のメソッドへのアクセスを提供します。その意味を理解するには、次の簡単なコードの使用は、あなたが実際に必要なすべてのCRUD操作を作成していることを認識し、クラス階層のドメインに、そして最終的にはリレーショナルデータベース層への層によって、HTTP RESTサービス層から放送してください。以下は、全体のコード・コントローラ・エンドポイントです。
[Route("api/todo")]
public class TodoController : CrudController<www.Todo, db.Todo>
{
public TodoController(ITodoService service)
: base(service)
{ }
}
このコードは、5つのHTTP RESTエンドポイント、あなたが作成することができ、読み取り、更新、削除データベースエントリとカウントを提供し、これは奇跡だろう。全体のコードは、「宣言」しており、任意のライン機能が含まれていません。もちろん、コード自体は生成されませんが、舞台裏で行われる作業のほとんどが、ここでのコードは、「スーパードライ」となっています。抽象度の高いを使用すると、本当の利点があります。C＃のIF-THENステートメントとベースアセンブリ言語コードとの嵌合関係の例。私は抽象化のより高いレベルのためにハードコーディングコントローラコードよりも概説している方法。
本実施形態では、www.Codeタイプはモデルのビューである、db.Todoタイプは、データベースモデル、およびサービス実装ITodoServiceあります。ちょうどあなたが永続的な基底クラスにほのめかしたいものを入力し、あなたはあなたの仕事をやったと言うことができます。サービス層は、空です。あなたはここにそのコード全体を見ることができます：
public class TodoService : CrudService<Todo>, ITodoService
{
public TodoService([Named("default")] ISession session)
: base(session, LogManager.GetLogger(typeof(TodoService)))
{ }
}
ゼロ方式、ゼロ財産、ゼロ磁場が、それでもフルサービス層TODO項目があります。実際には、でも、サービス・インターフェースは空です。以下に示し、全体のコード・サービス・インターフェース：
public interface ITodoService : ICrudService<Todo>
{ }
同じは空です！しかし、シムsalabim、アブラkadabra、あなたは完全なTODO HTTP RESTのWeb APIアプリケーションを持っています。データベース・モデルを開く場合は、以下を参照してください。
public class Todo : Model
{
public virtual string Header { get; set; }
public virtual string Description { get; set; }
public virtual bool Done { get; set; }
}
同様に、何も、わずか数の仮想ベースクラスの属性がありません。ただし、データベースに永続入力することができるようになります。データベースとフィールドタイプの間の実際のマッピングはmagic.todoプロジェクトTodoMap.csクラスで発生します。ここでは、クラス全体を見ることができます：
public class TodoMap : ClassMap<Todo>
{
public TodoMap()
{
Table("todos");
Id(x => x.Id);
Map(x => x.Header).Not.Nullable().Length(256);
Map(x => x.Description).Not.Nullable().Length(4096);
Map(x => x.Done).Not.Nullable();
}
}
このコードはドスが主キーとしてId属性ライブラリテーブルをORM、およびいくつかの追加属性/属性の残りの列を設定して示しています。（注）このプロジェクトではなく、さらにデータベースを起動するときに。データベーステーブルが存在しない場合は、NHibernateのは、それらを自動的に作成するためです。でも、接続文字列を必要としない魔法のデフォルトのSQLite、以来。あなたがMySQLやMSSQLを使用して接続設定をappsettings.configに覆われていない限りそれは、相対ファイルパスSQLiteデータベースファイルに基づいて自動的に作成されます。
信じられないかもしれませんが、あなたのソリューションを透過的に使用すると、リレーショナルデータベースと考えることができますほとんどすべてをサポートしてきました。実際には、これを機能させるためには、あなたは、コードの一行だけがConfigureNinjectクラスに位置してmagic.todo.servicesプロジェクト、で見つけることができます追加する必要がありますが、サービス・インターフェースとサービス・インプリメンテーション間の結合します。したがって、我々は最終的に、アプリケーション全体を取得するコードの行を追加し、言うことができます。ここでは唯一の実用的なアプリケーションは、TODO「コード」の行を作成するために使用されます。
public class ConfigureNinject : IConfigureNinject
{
public void Configure(IKernel kernel, Configuration configuration)
{
// Warning, this is a line of C# code!
kernel.Bind<ITodoService>().To<TodoService>();
}
}
OOP、ジェネリック医薬品とDRY原則をインテリジェントに使用することにより、我々は、スーパードライの魔術師となっています。したがって、疑問が生じる：より良いコードを作るために、このメソッドを使用する方法？
答えは次のとおりです。モデルを完了するために、フォルダに新しい項目を追加することができ、独自のモデルクラスを作成し、モデルのデータベースから始め、また、既存のmagic.todo.modelプロジェクトに新しいクラスを追加することによって行うことができます。次に、サービス・インターフェース契約のフォルダを作成します。今、サービスフォルダにサービスを実装し、ビューモデルとコントローラを作成します。サービス・インターフェースとサービス・インプリメンテーション間の結合ことを確認してください。新しいプロジェクトを作成することを選択した場合次に、あなたは必ずASP.NETコアは、それへの参照を追加するmagic.backプロジェクトでアセンブリをロードすることを確認しなければなりません。のみのサービスとバックエンド・コントローラーのニーズが参照されることに注意してください。
既存のプロジェクトを使用することを選択した場合は、最後の部分でも必要ありません。ただ、実際のコードの行を結合界面のサービス実装とサービスの間、あなたは完全なASP.NETコアウェブAPIソリューションを作成することができます。あなたは私に言わせれば、私はそれは強力なコードの行であると言うでしょう。youtu.be/M3uKdPAvS1Iへのアクセスは、私の「ASP.NETコアスーパーDRYマジック」ビデオでコードの全体の動作以前のバージョンを参照してください。
あなたはベースフレームを構築し、自動的にそれがどうなるか、データベース・スキーマに基づいており、この目的のためのコードを生成することができることを実現する際には、想像してみてください。このとき、ベースフレームコンピュータソフトウェアシステムは、コードを書いている、プロセスにおける完全なドライブ設計の有効なドメイン（DDD）アーキテクチャを生成します。
いいえコードなし、バグ、問題なし
ほとんどの台座のショートカットアプリケーションフレームワーク、及びその変形例、あるいはそれが不可能実用的なアプリケーションでそれらを使用することができ、生成されたコードの拡大を防ぎます。マジックでは、これは単に欠点ではありません。それはあなたのためのサービス層を作成し、コントローラにサービス・インターフェースを注入する依存性注入を使用します。また、あなたのために完全に効果的なDDDモードを生成します。初期のコードを作成した後、溶液の各部分が拡大し、必要に応じて変更することができます。SOLIDプロジェクトは完全にそれぞれの文字に検証されます。
例えば、私自身の溶液中で、私のサービスが抽出スレッドへのPOP3サーバーを持って、それがEmailAccountドメインモデルの型宣言です。バックグラウンドスレッドで実行されている。このPOP3サービス、私のPOP3サーバからデータベースへの電子メールストレージ。あなたは電子メールを削除すると、ユーザーがEmailAccountを削除した場合、私は確信しても、物理的にアクセサリーストアを削除したい、私は明らかにそれに関連付けられた電子メールを削除したいです。
コードはすべての電子メールや添付ファイルを削除する必要がありEmailAccount I削除操作を書き換える方法を図1に示します。記録のために、データベースと通信するためのHibernateクエリ言語（HQL）を使用します。NHibernateは、自動的にそれが物理的にどのデータベースに接続されているかどうかに応じて、正しいSQL構文を作成することをこれが保証されます。
図1は、削除EmailAccountに書き換え
public sealed class EmailAccountService : CrudService<EmailAccount>,
IEmailAccountService
{
public EmailAccountService(ISession session)
: base(session, LogManager.GetLogger(typeof(EmailAccountService)))
{ }
public override void Delete(Guid id)
{
var attachments = Session.CreateQuery(
"select Path from EmailAttachment where Email.EmailAccount.Id = :id");
attachments.SetParameter("id", id);
foreach (var idx in attachments.Enumerable<string>())
{
if (File.Exists(idx))
File.Delete(idx);
}
var deleteEmails = Session.CreateQuery(
"delete from Email where EmailAccount.Id = :id");
deleteEmails.SetParameter("id", id);
deleteEmails.ExecuteUpdate();
base.Delete(id);
}
}
数学を行います
あなたは概念について哲学的に考えることを始めると、インスピレーションが打たれます。例えば、マジックを中心に構築された台座フレームワークを想像してみてください。数学的な観点からは、あなたが100回の表、10列の平均各テーブルを含むデータベースを持っている場合、あなたはコストが急激に増加するコードの行の合計数を計算することがわかります。例えば、HTTP RESTのAPIへのすべてのこれらのテーブルを包装するために、各サービス・インターフェースがコードの7行を必要とし、各サービスの各テーブルは、コードの14行を必要とし、各テーブルコントローラはコードの各々19本のラインのために必要とされます。****図2関わる要素と必要なコードの行の動作を制御します。
図2は、コードのコストに追加され
| パッケージ | 契約 | コードの行の平均数 | コードの行の総数 |
| サービスインタフェース | 100 | 7 | 700 |
| サービス | 100 | 14 | 1400 |
| コントローラ | 100 | 19 | 1,900 |
| サービス・インタフェースと実装 | 100 | 1 | 100 |
| ビューモデル | 100 | 17 | 1700 |
| データベースモデル | 100 | 17 | 1700 |
| データベースのマッピング | 100 | 20 | 2,000 |
| コードの行の合計数： | 9,500 | ||
導入および操作が完了したら、あなたは、コードの9500行が表示されます。あなたは、メタデータ抽出サービス既存のデータベース・スキーマを生成することができた場合は、明らかに、あなたはこのコードを生成するために、ベースフレームを使用することができ、私たちが言うことができ、そして、それは、完全に任意のコード化を回避し、それでも音の枠組みにコードの9500行を生成し、拡張することは容易ですデザインパターンとベストプラクティスすべての関連。台座を構築するためにわずか2秒、コンピュータが仕事の80％を完了します。
今しなければならないことは、プロセスの構築トラバーサル方法台座結果であり、サービスやコントローラのドメインタイプを書き換え、何らかの理由で、あなたがこれに特別な注意を払う必要があります。あなたは、Web APIを完了しました。コントローラのエンドポイントは、単純なように生成読み取りAPI JSON闊歩宣言ファイルとしてクライアント層で、このベースフレーム構築プロセスのコピー、まったく同じ構造を持っているので。これは、角度などのサービスレイヤを作成したり、反応することができます。これらはすべて、一般化し、回避の重複の原則に基づいて、予測可能な構造を持つためのコードとWeb APIです。
このような観点から、あなたは成功したHTTP RESTのWeb APIプロジェクトを作成して、その複雑さは二回シュガーCRMオープンソースプロジェクトとしてであってもよく、あなたは数秒で仕事の80％を完了しました。すべてのプロジェクトとメンテナンスを読みやすいコードを作成しているときは、構造のコンポーネントの標準化と再利用に基づくソフトウェア工場組立ラインを簡素化します。そして、いくつかの行動や特別なプロジェクトを変更する必要性は、エンドポイントコントローラの隣に、感謝を再利用して動的に依存せずに、途中でのWeb APIサービスにロードすることができます。
あなたはコンサルティング会社で働く場合は、おそらく年間それぞれの新しいプロジェクトに共通して対処する必要が同様のニーズを持つプロジェクトのいくつかの新しい種類を、開始します。クライアントのニーズと初期実装のいくつかを理解した後は、数秒以内にプロジェクト全体を完了するために、スーパードライの方法を使用することができます。もちろん、（例えば、認証および許可のような）共通のモジュールを識別することによって、要素の組合せは、さらに、プロジェクトで再利用することができます。一般的なWeb APIプロジェクトでこれらのモジュールを実装することで、あなたはどんな新しいプロジェクトに適用することができ、これらのプロジェクトは、新しいもたらすでしょう、あなたが前に同様の問題を見てきました。
記録を容易にするために、この音のシンプルですが、実際には重複を回避することは困難です。これは、繰り返し再構築する意欲が必要です。復興が完了すると、我々はさらに再構築する必要があります。しかし、メリットは無視することはできません。DRY原則は、単にモジュールを借り成分の組み合わせを魔法の杖台座を振って、既存の、あなたはほとんど魔法のコードを作成することができます。
最後に、ここに定める原則は、あなたが重複を回避しながら、独自のWeb APIを作成するための既存のベストプラクティスを活用することができます。このアプローチの提供多くの利点は、それはあなたがDRYの美しさを鑑賞することができます願っています。
トーマス・ハンセンは キプロスに住んでいる今、禅・ソフトウェア・ウィザードで、彼は機能の独自の方法で資金・技術取引システムを通じてソフトウェアのコードになります。
この記事のレビューに、次のMicrosoft技術専門家のおかげで：ジェームズ・マキャフリー
