[C#] Entity classes toevoegen, niet maken

[_Thanatos_]

Ik heb in C# een kleine webapplicatie met een LINQ-to-SQL class. Dat kan wat stored procs en wat UDF's oproepen, meer niet. De return types wil ik echter gebruiken uit mijn eigen brouwsel, niet dat VS voor mij bedenkt.

Ik heb dus een functie get_item die (nu) als retrun type get_itemResult toebedeeld krijgt. Hier wil ik vanaf en daarvoor had ik al mijn eigen ItemInfo class. Een simpele kale class, zonder toeters en bellen:

C#:

public class ItemInfo {
    public int ID { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    //En nog een paar...
}

Dat is het enige wat erin zit. Maar in de O/R designer van VS kan ik die class niet selecteren. Het enige dat er wil staan is "(Auto-generated Type)".

Als ik in de O/R designer een nieuwe class toevoeg, dan kan ik em wel kiezen als return type, maar dan wil ik dus mijn *bestaande* class erheen slepen/kopiëren. Dat gaat helaas niet.

De hamvraag is dus: zonder mijn class helemaal opnieuw te moeten maken (met de muis nota bene ), hoe krijg ik die O/R designer zover dat ie mijn class gaat gebruiken als return type?

[Verwijderd]

Eigen methods schrijven in partial classes?

[_Thanatos_]

Dat kan wel, maar werkt dat ook met properties? En, natuurlijk, een partial class. Uiteindelijk smaakt dat toch een beetje vies. Net alsof je een class definieert en zegt "mwoah deze is nog niet af, zie ergens anders maar dat je em goed maakt". Staat slordig. Beetje bij elkaar geraapt zooitje wordt het dan.

Uiteindelijk wil ik dus een doodnormale class met alléén wat properties gewoon zo als entity class gaan gebruiken. De class past naadloos op het datamodel, dus daar kan geen probleem zitten.

[EfBe]

_Thanatos_ schreef op maandag 09 juni 2008 @ 14:07:
Dat kan wel, maar werkt dat ook met properties? En, natuurlijk, een partial class. Uiteindelijk smaakt dat toch een beetje vies. Net alsof je een class definieert en zegt "mwoah deze is nog niet af, zie ergens anders maar dat je em goed maakt". Staat slordig. Beetje bij elkaar geraapt zooitje wordt het dan.

tja, dat is inheritance dan ook, toch? Type B, dat erft van A heeft zijn code in 2 classes zitten, oh my!

Het komt lullig over, maar dat moet dan maar, maar je stelt je aan: je moet de applicatie maken met de tools die je in staat stellen de _applicatie_ te maken, want dat verwacht de opdrachtgever normaliter van je, en de applicatie is niet de plumbing om data in/uit de database te krijgen, maar de code die specifiek voor jouw applicatie is, dus business rules, validatie etc.

Uiteindelijk wil ik dus een doodnormale class met alléén wat properties gewoon zo als entity class gaan gebruiken. De class past naadloos op het datamodel, dus daar kan geen probleem zitten.

Tja, maar dat werkt niet met die designer van ze. Je moet dan de mappings zelf maken in de dbml file en in de datacontext class. Je wordt er niet vrolijk van maar het kan wel.

het punt is echter: het is volledig irrelevant. Jij zit je blind te staren op een belemmering die jezelf creeert: immers, je wilt een class C gebruiken ipv een class C', die voor je gemaakt wordt. Beide kunnen ze bevatten wat je wilt, en beide kun je gebruiken in de code die je moet maken voor je applicatie, echter jij wilt per-se C gebruiken en niet C'. En dat terwijl het _BEIDE_ classes zijn voor het representeren van een entity definitie, en NIET de entity definitie an sig zijn. Die is nl. abstract.