(小ネタ)Table-Per-Hierarchy とは
仕事の都合やら、質の高い内容を書こうとしたせいで、4か月近く更新が出来ていませんでした。今日からリフレッシュして、改めて気負わずに記事を書いていきたいと思います。
Entity Framework 6とEntity Framework Coreの違いを紹介した記事を読んでいて、その中でEntity Framework Coreは、Table-Per-Hierarchy (TPH) のみ対応という記述が出てきた。
Feature Comparison | Microsoft Docs
Table-Per-Hierarchyとは何だろう?と思って調べてみると、書籍「SQLアンチパターン」の5章で紹介されているシングルテーブル継承(Single Table Inheritance)の事だという事がわかった。
Entity Frameworkでサポートしているのは驚きだった。でも、なんでわざわざ別の名前をつけたのだろうか。Hibernate(JavaのO/Rマッパー)でも同じ名前が使われているみたいだが、新たなパターンかと思ってしまった。
バリデーションのメッセージを変更する
ASP.NET MVCの入力値の検証は便利ですよね。デフォルトでもメッセージの意図は伝わります。
でも、カラムに必ず○○フィールドは~とつくため、これをなくしたい場合もよくあると思うので変更方法を調べました。
ちなみに、良くあるバリデーションのメッセージを手間をかけずに変更したいので、カスタムValidationについては書いていません。
バリデーションエラーのメッセージを変更したい場合
検証に使用している属性の ErrorMessage プロパティにメッセージを設定します。
第3回 モデル・バインドとアノテーション検証の実装 − @IT
日付型や数値型に別の型(文字列)が入力された時のメッセージを変更したい場合
以下のサイトの2番目の回答(29ポイントのやつ)が大事です。 stackoverflow.com
Global.asax
の修正とリソースファイルの作成だけで変更が出来ます。
日付型のメッセージを変更したい場合は、FieldMustBeDate をキーとしてリソースファイルに値を設定します。
数値型の場合は、FieldMustBeNumeric がキーです。
※バリデーションのメッセージとは異なる扱いなので注意。
属性による検証のメッセージでリソースファイルを使用したい場合
以下のサイトの回答が参考になります。 stackoverflow.com
なお手元の環境では、App_GlobalResources.Messages
を Messages
にして、using Resources;
を追加する必要がありました。
必須(Required)属性のメッセージを一括変更したい場合
必須属性のメッセージにリソースファイルを使用する場合や、属性に毎回設定を書きたくない場合は、以下のサイトとリンク先を読むと良いです。
内容に従って、クラスを作成すると必須属性からErrorMessageの指定を削ることが出来ます。
実際どうしたか
最後に、バリデーションのメッセージ変更方法はいくつかありますが、実際のプロジェクトではどうしたかを備忘録として書いておきます。
- 日付/数値型の不一致の場合……リソースファイルを使用
- それ以外……属性のErrorMessageプロパティで指定
必須(Required)属性のアダプターは、一度作成してみたのですが、それ以外に正規表現(RegularExpression)、メールアドレス(EmailAddress)、URL(Url)、範囲(Range)属性等々も使用しているため、各々の属性についてアダプターを作成する手間がかかります。
また、既にErrorMessageプロパティに設定する方法でだいぶ進めてしまったので、手間やわかりやすさを考慮した結果、上記のようになりました。
落ち着いた段階でリソースファイルを参照するように直していきたいと思います。
動作環境
- ASP.NET MVC 5.2.3
Entity Framework で既存DBを使用した時にログ出力されるエラーの解消方法
新年一つ目の記事ということで、あけましておめでとうございます。今年もよろしくお願いいたします。
Entity Framework を使用して開発を進めていく場合に、開発中は Code First を使用してDBを再作成するけれど、 本番環境やステージング環境には既にDBが用意されていることが多いと思います。
その場合、データベースイニシャライザーを変更して、DBを再作成しないようにします。
この状態で公開(発行)すると、テーブル名やカラム名と対応するModelクラスのプロパティ名が一致していれば動作しますが、
ログ出力を設定していると以下のエラーが記録されています。
エラー: オブジェクト名 'dbo.__MigrationHistory' が無効です。
このエラーの解消方法を調べました。
dboスキーマに __MigrationHistory テーブルが無いので作れば良いのかと思ったのですが、わざわざ作る必要はありませんでした。
以下のようにGlobal.asax
等で、データベースイニシャライザーに null を設定して、起動時に __MigrationHistory テーブルの存在をチェックに行かないようにすればOKでした。
Database.SetInitializer<DbContextを継承したクラス名>(null);
以上です。
環境
- Entity Framework 6.1.3
ASP.NET MVC でユーザの氏名(!=アカウント名)を表示する(Windows認証を使用)
ASP.NET MVC で Windows認証を使用して、ログインアカウント名(ドメイン名\アカウント名)からユーザーの氏名(フル・ネーム:Full Name)を取得して画面に表示する方法を調べたら、以下のサイトに書いてあった。
上記サイトが見れなくなった時のために、ソースコードを載せておく。
using (var context = new PrincipalContext(ContextType.Domain)) { var principal = UserPrincipal.FindByIdentity(context, User.Identity.Name); var firstName = principal.GivenName; var lastName = principal.Surname; }
PrincipalContextクラス、UserPrincipalクラスを使用してアカウント名から、ユーザーの氏名を取得している。
実際に使ってみた注意点としては
アセンブリ参照の追加が必要
Visual Studio上で[参照マネージャー]画面の[アセンブリ] > [フレームワーク]から、System.DirectoryServices.AccountManagementをチェックする。
DLLの実行環境へのコピーを設定しておくと良い
ソリューションエクスプローラーで参照の配下にある System.DirectoryServices.AccountManagement を選択して、プロパティウィンドウの[ローカルにコピー]を True に設定すれば、プロジェクト直下ある Web.config の書き換えが不要になる。
(設定しない場合は、Web.config を書き換える必要がある)Viewsディレクトリの下にある Web.config で namespace の設定をすれば、cshtml で使用する場合に @using が不要になる。
_Layout.cshtml 等のレイアウトに設定することが多いと思うが、毎回呼び出される個所なので、負荷がかからないように対策(キャッシュ等)を行う。
Web Deployの整理
ASP.NET MVC 5 の Web Deploy について自分用にまとめたメモ。
2018/12/11 追記
作業手順の順番を変更しました。
旧)Web Deploy 3.6のインストール→管理サービスのインストール
新)管理サービスのインストール→Web Deploy 3.6のインストール
対象環境
Web Deployment Agent Service と Web Management Service どちらを使う?(サーバー側)
Web Deployment Agent Service=Remote Agent Service
- 日本語では「Web 配置エージェントサービス」とか「リモート エージェント サービス」と呼ばれる。
- Windows Server 2003/IIS 6 は、これ一択。
- Web Deployのインストール時に、選択する必要あり。
- 管理者のみ使用可能。
参照URL:Introduction to Web Deploy | Microsoft Docs
Web Management Service(WMSVC)=IISの管理サービス
- 日本語では「Web 管理サービス」「IIS 管理サービス」と呼ばれる。
- Windows Server 2008/IIS 7 から登場した。
- サーバーOSに搭載されている。(参照URLより。最新OSは確認していない)
- 設定を行うことで、管理者以外も使用可能。
参照URL:Visual Studio 2010 [発行]機能で配置可能とするためのサーバー設定 – monoe's blog
Visual Studio と WebMatrix どちらを使う?(クライアント側)
Visual Studioで公開する場合
Visual Studioの公開(発行)は、Web Deployment Agent Service、Web Management Service の両方を使用可能。
WebMatrixで公開する場合
WebMatrixのWeb Deployは、Web Management Serviceを使用する。
Web Deployを行うユーザーは、Windowsユーザー(ドメインユーザー)とIISの内部ユーザー(IISマネージャー ユーザー)どちらを使う?
Windows ユーザーを使用する場合
特に追加の設定なし
IIS 内で完結するユーザー(IISマネージャー ユーザー)を使用する場合
「IIS マネージャー ユーザー」を選択して、ユーザーを追加する。
参照URL:IIS 7の新しい運用形態 | Think IT(シンクイット)
実際に選択したのは?
サーバー側:Web Management Service
Web Management Serviceの方が新しく、機能も充実しているので、使わない手はない。
クライアント側:Visual Studio
Visual Studioを使用して開発しているため。
Web Deployを行うユーザー:Windowsユーザー(ドメインユーザー)
ドメインユーザー以外は、Web Deployを行わないため。
作業手順
上記条件でWeb Deployを行う場合のサーバー側の作業手順を以下にまとめる。
.NET Framework 4.6のインストール
サーバーマネージャーを起動し、[サーバーの役割] で [Web サーバー(IIS)] > [管理ツール] > [管理サービス] をインストール
Web Deploy 3.6のインストール
セットアップの種類で「完全」を選択する。
もしくは、リモート エージェント サービスは不要なのでインストールしない。それ以外はインストールする。IIS マネージャーを起動し、[管理サービス] で [リモート接続を有効にする] をチェックする。
Web Deployに必要。有効にしないとローカルコンピューターからしか管理サービスに接続できない。Web Deploy対象のサイトを右クリックし、[展開] > [Web 配置による発行の有効化] を行う。
- ユーザーを入力する。プルダウンに無い場合は右側のボタンを押下して選択する。
- 保存先を指定する。
保存された設定ファイルは、開発環境でインポート出来る。
「管理サービスの委任」の設定が行われる。(一部の設定は、「接続の検証」時に行われているかもしれない)
ユーザーのアクセス許可を設定する必要はあるか?
[Web 配置による発行の有効化] で選択したユーザーは設定されているので、新たに設定する必要はない。
管理サービスの委任を設定する必要はあるか?
[Web 配置による発行の有効化] で選択したユーザーは設定されているので、新たに設定する必要はない。
フォルダのアクセス権限を編集する必要はあるか?
[Web 配置による発行の有効化] を行ったサイトのフォルダ(Default Web Siteならば、wwwrootフォルダ)に対して、選択したユーザーにはフルコントロールが与えられるので、新たに設定する必要はない。
参照URL:
Visual StudioのWeb発行がどうしても上手くいきません
https://officeyuai.net/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%96%8B%E7%99%BA/net-mvc/mvc_trable1/
その他・関連用語
Windows Process Activation Service(Windows プロセス アクティブ化サービス:WAS)
WCFでHTTPだけでなく、他プロトコルの通信もサポートするためのもの。Web Deployment Agent Serviceと勘違いしやすい。ポート80をリッスンしている。
World Wide Web Publishing Service(World Wide Web 発行サービス:W3SVC)
IISを起動・停止するためのサービス。Web Management Serviceと勘違いしやすい。
git-flow や GitHub Flow を運用しやすいようにアレンジして使っていました
ちょっと前の開発プロジェクトで使っていたGitを使用したワークフローについて書いてみます。
ざっくり言うと、リポジトリを一つしか使用しない git-flow って感じです。もしくはルールを追加した GitHub Flow でしょうか。
以下、箇条書きで書きます。
master, develop, featureブランチを用意します。機能を実装するときは、developerブランチからfeatureブランチ配下に「今日の日付+バックログ項目やタスクのID」という命名でブランチを作成します。
featureブランチは実装中、ある程度のまとまりでサーバーにプッシュします。実装完了後は、サーバー上でプルリクエストを作成してレビューを行い、レビューが完了したらdevelopブランチにマージします。
リリースを行う時は、最新のdevelopブランチから、release作業用ブランチを作成して、リリース準備作業を行ったらmasterブランチ(とdevelopブランチ)にマージし、masterブランチをサーバーにプッシュしてから、masterブランチにてリリースデプロイを行います。
コードレビューは、既に書きましたがfeatureブランチからdeveloperブランチへのマージ時に行います。リリース作業のチェックは、プッシュ後にmasterブランチで確認します。
ツールは、git-flow関連はSourceTreeを使っていて、それ以外は必要に応じてコマンドラインなども使用していました。
プルリクエストを作成するまでは、featureブランチは担当者専用のブランチなので、ローカルのブランチでコミットの順番を入れ替えたり、集約してコミットログを整理した後、サーバーに強制プッシュすることもOKです。
CI/CDを行うとしたら、feature->developへのマージ後や、masterのプッシュ後になると思います。
プロジェクトは変わってしまったのですが、中々良く出来ていると思ったので、覚えている限り書いてみました。