9 svar · 648 visningar · startad av Bjuris
Jag har en stored procedure som jag kan komma åt bland mina entities.
problemet är att min stored procedure räknar ut data från en massa olika tabeller och skapar "nya fält" typ totalMessages osv.
Denna totalMessages kan jag inte mappa mot någon av mina entities. Iom att det är ett beräknat fält och inte finns i databasen/entities
Hur skall man göra?
Man kan ju skapa en ny entity men då har jag samma problem att den måste mappas på något sätt.
du kan skapa en vy i databasen baserat på din stored procedure, lägga till den i entity framework designern så är saken biff. Tyvärr är det en väldigt dålig lösning.
Entity Framwork tillåter ju partial classes så varför kör du inte lite extensions via partal classes
partial class Entity
{
public int TotalMessages { get; set; }
}
vet ej om det fungerar men själv brukar jag låta bli stored procedures och göra logiken för uträkningar i C# istället. Ett ställe mindre att ändra på samt hastigheten det tar att få något färdigt.
Försöker väl även jag komma ifrån sp'na men i detta fall så är det en gammal sp som redan är färdigskriven (kanske inte på bästa sätt, men den ger mig informationen jag vill ha), som är riktigt stökig.
Jag har alltså inte ork, tid eller lust :h att skriva om den...
Har pillat lite med partial klasser nu och det verkar fungera.
Problemet är dock inte löst
Får följande fel:
The data reader is incompatible with the specified BusinessEntities.MyPlan_Answers'. A member of the type, 'Answer', does not have a corresponding column in the data reader with the same name.
Och det är ju klart att jag får detta då jag inte plockar ut Answer ur min sproc.
Någon som stött på problemet förr?
CatZ skrev:
du kan skapa en vy i databasen baserat på din stored procedure, lägga till den i entity framework designern så är saken biff. Tyvärr är det en väldigt dålig lösning.
Entity Framwork tillåter ju partial classes så varför kör du inte lite extensions via partal classes
Av ren nyfikenhet, varför blir en vy så mycket sämre att det är värt att bloata ner sina klasser med en massa extra properties för att undvika det? (Och varför göra det som partial class?)
spango skrev:
Av ren nyfikenhet, varför blir en vy så mycket sämre att det är värt att bloata ner sina klasser med en massa extra properties för att undvika det? (Och varför göra det som partial class?)
För att det är en enkel och snabb lösning! :P
spango skrev:
Av ren nyfikenhet, varför blir en vy så mycket sämre att det är värt att bloata ner sina klasser med en massa extra properties för att undvika det?
Hur vet du att han "bloata ner sina klasser" det kanske är så att just den properties är vital för domänmodellen och allmänt känd.
Bara för att den inte finns i databasen så betyder ju inte det att man "bloatar ner sina klasser", klasserna behöver ju knappast återspeglas i databasmodellen....
- M
Gladh skrev:
Hur vet du att han "bloata ner sina klasser" det kanske är så att just den properties är vital för domänmodellen och allmänt känd.
I sådana fall måste jag ha missförstått frågan. Jag fick intrycket av att EF kräktes för att den hittade en kolumn i svaret från SPn som den inte kunde mappa mot ett fält i entiteten, och att OP egentligen inte var intresserad av att få med det värdet utan bara ville att EF skulle tiga, utan att behöva skriva om sin SP. I min åsikt hade det då varit att bloata klassen om man stoppade in ett fält som man aldrig använder bara för att få tyst på O/R-mappern. (Det låter också som en tråkig egenskap hos O/R-mappern om man inte kan be den att strunta i vissa kolumner, men det är en annan sak.)
Kvarstår dock varför man vinner på att göra klassen partial, eftersom det är en egenskap som enbart berör kompilatorn.
Det finns än till och med tråkigare lösning men en som förmodligen är "mer rätt" om du nu ska använda dig av stored procedures och det är att generera dina amppningsfiler till bin och sedan ändra manuellt. Se http://msdn.microsoft.com/en-us/library/bb399785.aspx && framför allt! http://msdn.microsoft.com/en-us/library/bb896279.aspx