ASP.NET MVC en HTML5 JavaScript-gegevenspraktijken

Ik probeer de beste manier te vinden om gegevens op mijn webpagina's te krijgen voor gebruik in JavaScript.

Het grootste deel van mijn ervaring is desktopland in .Net (WPF, enz.).

Technologie:

Ik gebruik momenteel ASP.NET MVC3. Ik heb een hele reeks bedrijfslaagmodellen. Deze modellen kunnen soms interessante relaties hebben. Ik moet deze modellen naar de client sturen en dingen in JavaScript met ze doen en ze dan terugsturen naar de server voor persistentie en andere bedrijfslogica.

Kernwaarden:

Ik zou graag een oplossing willen vinden die de koppeling tot een minimum beperkt, de code/functionaliteit-duplicatie tot een minimum beperkt, de scheiding van problemen ondersteunt en gemakkelijk te onderhouden is (IE begrijpelijk, weten waar te veranderen, enz.).

Er zijn een paar manieren om dit aan te pakken waar ik aan heb gedacht. Beide lijken te kort te schieten.

Optie 1:

Maak JavaScript-versies van mijn modellen die ik JavaScript View Models (JSVM's) zal noemen. deze JSVM's worden gemaakt via Ajax-oproepen. De JSVM's worden toegewezen aan gegenereerde JavaScript-objecten op basis van de servermodellen. Dat betekent dat er ergens een "Map" "klasse" is die de kaarten van en naar deze twee modellen afhandelt (om koppeling te verlagen en SoC te behouden).

Nadeel, veel code duplicatie. Wanneer u het JSVM- of het servermodel wijzigt, moet u deze toewijzingstabel mogelijk wijzigen.

Dit lijkt slechts enkele van mijn problemen op te lossen.

Optie 2:

Ik vond een bibliotheek met de naam "FluentJson.Net". Het stelt me ​​in principe in staat om JavaScript-objecten van knock-out JS van scheermes inline te maken. Vanaf daar kan ik eigenlijk gewoon coderen tegen dit object dynamisch creëren. Het is niet nodig om de JSVM's te maken.

Nadeel: er is een zeer nauwe koppeling met het model aan de serverzijde. Een verandering in het servermodel kan de nodige wijzigingen op meerdere pagina's veroorzaken!

Er zijn waarschijnlijk enkele combinaties van optie 1 en optie 2 die ik zou kunnen verkennen, maar ik neem aan dat ze allemaal nadelen hebben.

vragen:

Wat ik echt zou willen weten is: wat zijn de best practices voor het omgaan met modellen op de server en de client? Is er een oplossing die mijn kernwaarden behoudt?

(Bewerken: het volgende voorbeeld toegevoegd)

Voorbeeld:

C # -modellen:

public interface IChartDefinition{
    string Name{get; set};
    IEnumerable Series {get; set;}
}

public interface IChartSeries{
    Color Color{get; set;}
    Name {get; set;}
}

Op de server definieert deze definitie de basisgrafiek. Deze diagramdefinitie wordt bewaard in een database en kan later worden opgerold en gebruikt met echte gegevens om een ​​diagram weer te geven op de client.

Ik heb een controller genaamd "ChartDesignerController" en het is de basisfunctie om mensen hun diagramdefinities te laten beheren.

Dus ik heb een weergave voor Create voor het maken van een diagramdefinitie. Naar mijn mening wil ik een + -knop om reeksen toe te voegen. als series worden toegevoegd, wil ik dat de gebruikersinterface opties voor de reeks weergeeft, zoals kleur en naam. De gebruiker kan series etc. verwijderen

Al deze interactie wordt gedaan met JavaScript op onderliggende JavaScript-objecten die deze gegevens bevatten tot de eindgebruiker op de verzendknop drukt en deze gegevens terugstuurt naar de server om aanhoudend te zijn.

Deze javascript-objecten zien er bijna identiek uit als de C# -modellen die blijven bestaan.

1
Optie 3: gebruik JavaScript op de server en hergebruik de server/client van uw bedrijfsmodellen. U hebt in feite een kernmodel en uw server erft van en uw client erft van. Dit maximaliseert het hergebruik van code door overerving
toegevoegd de auteur Raynos, de bron
Ik zie niets in uw kernwaarden dat het maken van Javascript-modellen verplicht stelt. Waarom denk je dat je dat moet doen? Waarom kan je het asp.net MVC-model met validatie attirubtes niet gebruiken om de client-side validatie van je model uit te voeren?
toegevoegd de auteur Ryand.Johnson, de bron
Waarom heeft u het model op de client anders nodig dan voor weergave? In het java-script ga je werken met de objecten op de pagina en hun waarden, wat zou het voordeel zijn van het dupliceren van je MVC-structuur in javascript?
toegevoegd de auteur Maess, de bron
Misschien is dat een deel van mijn probleem. Veel functionaliteit moet representatief zijn voor de klant. Die gegevens moeten daar ergens bestaan ​​en vervolgens worden teruggestuurd naar de server om wijzigingen aan te brengen. Ik denk niet dat ik mijn hele set modellen moet dupliceren, maar dat sommige ervan op de server moeten worden weergegeven voor manipulatie.
toegevoegd de auteur Mike Bynum, de bron
Suggereer je Node.js? Ik werk met asp.net MVC. Ik ben niet op de hoogte van een complete oplossing voor ASP.NET MVC met Node.js.
toegevoegd de auteur Mike Bynum, de bron
Ik ga een voorbeeld toevoegen aan mijn oorspronkelijke vraag om mijn betekenis te valideren.
toegevoegd de auteur Mike Bynum, de bron

Geen antwoorden

0