Möchte man Tabellen nicht direkt mappen, kann auf die Möglichkeit, Views auf Klassen zu mappen und Inserts, Updates und Deletes über Stored Procedures stattfinden zu lassen, ausgewichen werden. Soll sich der SQL-Code zum Laden, Einfügen, Speichern und Löschen jedoch im EDM wiederfinden, können diese Stored Procedures und diese View auch direkt innerhalb des Storage-Models im EDM definiert werden. Da es somit sein kann, dass bestimmte im Storage-Model definierte Tabellen nicht mehr gemappt sind (weil sie ja über die View und die SPs gemappt sind) müssen diese entfernt werden.
Der Nachteil dieser Lösung: Man muss dies manuell also direkt im XML-File machen und beim nächsten Update Model from Database gehen solche Änderungen verloren.
Nachfolgend ein paar Snippets, die dieses Szenario skizzieren.
Native Funktion im Storage Model:
<Function Name="Rtlwtz" IsComposable="false">
<CommandText>
insert into Hotel2(Bezeichnung, Sterne, RegionId, BildPfad)
values (@Bezeichnung, @Sterne, @RegionId, @BildPfad);
select SCOPE_IDENTITY() as HotelId;
</CommandText>
<Parameter Name="Bezeichnung" Type="varchar" />
<Parameter Name="Sterne" Type="int" />
<Parameter Name="RegionId" Type="int" />
<Parameter Name="BildPfad" Type="varchar" />
</Function>
Die View im Storage Model als EntityType:
<EntitySet Name="CustomHotel" EntityType="HotelDbModel.Store.CustomHotel" store:Type="Views">
<DefiningQuery>
select
HotelId,
Bezeichnung + '!' as Bezeichnung,
Sterne * -1 as Sterne,
BildPfad,
RegionId
from Hotel
</DefiningQuery>
</EntitySet>
Der Type für den EntityType:
<EntityType Name="CustomHotel">
<Key>
<PropertyRef Name="HotelId" />
</Key>
<Property Name="HotelId" Type="int" Nullable="false" />
<Property Name="Sterne" Type="int" />
<Property Name="Bezeichnung" Type="varchar" />
<Property Name="BildPfad" Type="varchar" />
<Property Name="RegionId" Type="int" />
</EntityType>
Feed
Twitter
XING
