Eugenio Pace – Software as a Service Architecture Guidance
Published Wednesday, March 19, 2008 11:05 AM by eugeniop
From <http://blogs.msdn.com/eugeniop/archive/2008/03/19/litwarehr-on-ssds-part-ii-the-data-access-layer.aspx>
LitwareHR on SSDS – Part II – The data access layer
The heart of LitwareHR implementation on SSDS is in it’s data access layer of course. In fact, we created two different, but functionally equivalent implementations: one runs against SQL (LitwareHR’s original implementation) and a second stack that runs against SSDS. Of course they are mutually exclusive and all layers above the DataModel cannot tell the difference.
SSDS 上の LitwareHR 実装における中心は、もちろん、そのデータ･アクセス･レイヤの中にある。現実に、私たちは、同じ機能を持つが、構造が異なる2つの実装モデルを作成した。ひとつは、SQL に接するかたちで実行され（LitwareHR のオリジナル実装）、二番目のスタック･モデルは、SSDS に接するかたちで実行される。もちろん、それらは相互に排他的であり、また、DataModel よりも上位にある、すべてのレイヤは相違を伝えることができない。
As illustrated in the diagram above, the key class is Repository<T>, which among other things encapsulates all access to SSDS, translates T’s into SSDS’s Flexible Entities and in general provides a higher level of abstraction on top of SSDS artifacts. For example, Repository deals with tenants, which are then mapped into Authorities & Containers by a provider. The default implementation of this simply does a 1:1 mapping between Tenants and Containers, being Authorities fixed (as specified in configuration), but because it is using a provider model, you can supply a more sophisticated implementation.
上記のダイアグラムに示されるように、キークラスは Repository<T> である。それは、他の階層にはさまれ、SSDS に対する全てのアクセスをカプセル化する。T に受け渡されたものは、SSDS の Flexible Entities に展開され、また、一般的には、SSDS アーティファクトのトップに、高抽象レベルを供給する。 たとえば、 Repository は tenants を取り扱い、続いて、プロバイダにより、Authorities & Containers の中にマップされる。 ここでのデフォルト実装は、Tenants とContainers の間で 1:1 でマッピングされ、（コンフィグレーションで指定されるように）Authority は固定されるが、プロバイダ･モデルが使われているため、さらに洗練された実装を提供できる。
T allows us to use typed objects that represent LitwareHR entities: Resumes, Positions, etc. so a hypothetical LitwareHR developer can write things similar to this:
T により、LitwareHR エンティティを表現するための、Resumes や Positions などの類型化されたオブジェクトが使用できるようになる。それによいり、想定される LitwareHR デベロッパーは、以下に類似したことを記述できる：
public class Position : ExtensibleEntity
{
public string Code {set;get;}
public string Location {set; get;}
}
Position p = new Position { Id = Guid.NewGuid(), Code = "Code_1", Location = "Location_1", };
p.Fields.Add( "YearsOfExperience", 15 );
In LitwareHR all entities derive from ExtensibleEntity which is just a simple helper base class that provides some useful fields such as: Id, a collection of fields, etc.
In the example above, Id comes from ExtensibleEntity, Code and Location are defined at design time by the developer and "YearsOfExperience" might be a field that a particular tenant is adding to this position. Because it is a tenant specific field, it is defined at runtime.
LitwareHR において、すべてのエンティティは、単なるヘルパー･ベースのクラスである ExtensibleEntity から生じる。そのクラスにより、たとえば field sのコレクションである Id のような、いくつかの有用なフィールドが提供される。上記のサンプルにおいては、デザイン･タイムにデベロッパーにより定義される、ExtensibleEntity／Code／Location から Id が生じている。そして「YearsOfExperience」は、このポジションに特定のテナントが加える、フィールドになるかもしれない。それは、テナントが特定し、ランタイムに定義されるフィールドになる。
Behind the scenes the Position entity will be translated into a SSDS flexible entity. Id, and Kind are intrinsic properties in SSDS and are automatically mapped into the Position.Id and typeof(Position).ToString(). The rest is mapped to flexible properties.
その背後において、Position エンティティは、SSDS の柔軟なエンティティに変換されるだろう。 Id と Kind は、SSDS の本質的なプロパティであり、Position.Id と typeof(Position).ToString() に自動的にマップされる。 残りのものは、柔軟なプロパティにマップされる。
All those details are of course handled by Repository<T>. Its interface is straight forward and looks like the one below, which is self-explanatory.
それら全ての細部は、もちろん、Repository<T> により操作される。 そのインターフェイスは単純なものであり、また、以下のように説明を要しないものである。
Insert( T );
T GetById( id );
IEnumerable<T> ListAll();
IEnumerable<T> Search( string query );
Delete( id );
Update( T );
So a complete snippet (taken from one of our tests) looks like this:
したがって、それらの断片をまとめたものは以下のようになる:
