Van ASPX Forms naar MVC5

[tha_crazy]

De afgelopen dagen ben ik bezig om van ASPX Forms (masterpages e.d.) over te stappen naar MVC.
Dit om mezelf natuurlijk meer te ontwikkelen en ik heb het ook nodig voor MCSD.

Nu heb ik het eea al wel onder controle, Ik snap wat de controllers doen, waar de models voor dienen en hoe dit soort "Master pages" werkt.
Mooi, tijd om er een database aan te hangen en eens goed te gaan stoeien.
Nou, met het goed stoeien ben ik al aardig wat dagen bezig

Initieel was het idee om er een MySQL DB aan te hangen, doe ik regelmatig, gebruik een simpel USB Webservertje ervoor en dat werkt wel aardig.
Na echter een tijd rotzooien met EF, ADO.NET EF, MySQL Connector en al die meuk lukte het niet.
Prima, Local DB dan maar.
Via Code First een model aangemaakt en EF6 de local DB aan laten maken, tot zo ver prima.
Alles werd netjes aangemaakt, evenals m'n views en dat werkte goed, maar ik heb het liever van mezelf zodat ik via een modal popup gewoon een AJAX call kan doen en alles on the fly werkt (zoals het nu doet in windows forms).

Dus de zooi weer verwijderd en verder gaan zoeken.

Na bezig te zijn geweest met Database first, en daarna code first beide via verschillende bronnen er nog niet uit gekomen.

Daarna ook nog het eea via membership gevonden, wat trouwens ook niet erg werkt want zodra ik bij een controller een validate functie probeer uit te voeren

code:

return Membership.ValidateUser("User", "Password");

en de uitleg ervan is ook niet duidelijk.

Nu kan ik wel zeggen ik voeg een mapje classes toe, voeg de System.Data.SqlClient toe en ga op die manier aan de slag, maar dat lijkt mij ook niet de bedoeling.

Oftewel, wie kan hier wat duidelijkheid in verschaffen?

Ik wil gewoon in mijn pagina een AJAX call naar een controller welke voor mij het wachtwoord hasht, valideert, en een true/false teruggeeft zodat ik deze in de huidige layout in kan bouwen.
Maar dit wel met een fatsoenlijke DB connectie, en of dat via membership of EF loopt, of voor mijn part via de SQLClient maakt me niet uit.

Overige bronnen trouwens die ik nu nog open heb staan:
http://www.codeproject.co...imple-Membership-Provider
http://azure.microsoft.co...rship-oauth-sql-database/
http://www.c-sharpcorner....and-logout-in-mvc-4-usin/
http://www.asp.net/mvc/ov...ls-data-from-a-controller

_{Ik hoop dat het een beetje duidelijk is, ik heb er koppijn van gekregen}

[Haan]

Je verhaal is een beetje warrig, en er lopen minstens drie zaken door elkaar heen die eigenlijk niks met elkaar te maken hebben.

Mijn advies: start eens een nieuw MVC5 project zoals dat meegeleverd wordt met Visual Studio. De standaard template bevat al een volledig werkende site met standaard inlogsysteem ingebouwd.
Ik denk dat je nu teveel dingen in 1x allemaal tegelijk aan het doen bent waardoor je nu inderdaad compleet het overzicht kwijt bent.

[FraxleNL]

Er zijn hier inderdaad meerdere scenario's in een. Het is misschien duidelijker als je je zaken kan scheiden van elkaar. Zorg er eerst voor dat je met jQuery AJAX een call kan maken naar een controller.

Kijk daarna hoe je een duidelijke database connectie kan maken met behulp van de EF, wat erg nauw samenhangt met het werken met ASP.NET MVC.

Als laatst kan je even gaan stoeien met de Membership methods.

Denk stapsgewijs na en neem niet teveel hooi op de vork als je begint met het werken / leren aan een ander concept. Zoals Haan al zegt, je wilt teveel en raakt daarom het overzicht kwijt. Als je probeert eerst deze zaken te scheiden van elkaar ben ik bereid om vanavond het een en ander te beantwoorden.

[Tribits]

Normaal gesproken zou ik naar Getting Started with ASP.NET MVC 5 verwijzen om een beetje thuis te raken in MVC5, leuke tutorial en mooi startpunt. Ik maak echter uit de topic start op dat je specifiek zit te worstelen met de authentication en authorization van de MVC applicatie. Daarover is de nodige informatie te vinden op deze site.

Specifiek wat betreft je opmerking over de database verbinding: als je een nieuwe MVC5 project aanmaakt wordt de userdata vanzelf al in de database opgeslagen. Het project wordt zo aangemaakt dat het framework daarvoor zelf de tabellen aanmaakt in de database waar ook de rest van je gegevens worden opgeslagen ("DefaultConnection"). Dit topic op stackoverflow geeft wel een aardige uitleg van hoe dat intern werkt. Specifiek je gebruikersnaam en wachtwoord hash belanden in een tabel genaamd AspNetUsers, kolommen UserName en PasswordHash. Zelf valideren lijkt me weinig zinvol, dit soort zaken zitten nu net in een framework om te voorkomen dat je het zelf moet implementeren maar vooral ook om te voorkomen dat je alle mogelijke gangbare (ontwerp)fouten maakt.

[tha_crazy]

Haan schreef op dinsdag 03 februari 2015 @ 15:54:
Je verhaal is een beetje warrig, en er lopen minstens drie zaken door elkaar heen die eigenlijk niks met elkaar te maken hebben.

Mijn advies: start eens een nieuw MVC5 project zoals dat meegeleverd wordt met Visual Studio. De standaard template bevat al een volledig werkende site met standaard inlogsysteem ingebouwd.
Ik denk dat je nu teveel dingen in 1x allemaal tegelijk aan het doen bent waardoor je nu inderdaad compleet het overzicht kwijt bent.

Klopt heb ik inderdaad gedaan, evenals de laatst genoemde "Getting started" doorgelopen.
Echter is dat wel allemaal zoals ik het juist niet wil hebben, daarnaast mis ik de uitleg wat sommige dingen nou precies doen _{heb al aardig wat uitgevogeld ondertussen}

en tja, te veel dingen door elkaar doen, dat doe ik standaard

FraxleNL schreef op dinsdag 03 februari 2015 @ 16:26:
Er zijn hier inderdaad meerdere scenario's in een. Het is misschien duidelijker als je je zaken kan scheiden van elkaar. Zorg er eerst voor dat je met jQuery AJAX een call kan maken naar een controller.

Kijk daarna hoe je een duidelijke database connectie kan maken met behulp van de EF, wat erg nauw samenhangt met het werken met ASP.NET MVC.

Als laatst kan je even gaan stoeien met de Membership methods.

Denk stapsgewijs na en neem niet teveel hooi op de vork als je begint met het werken / leren aan een ander concept. Zoals Haan al zegt, je wilt teveel en raakt daarom het overzicht kwijt. Als je probeert eerst deze zaken te scheiden van elkaar ben ik bereid om vanavond het een en ander te beantwoorden.

Persoonlijk werk ik liever iets anders, ik heb graag even eerst een database connectie open.
Hiervoor heb ik en testcontroller gebouwd waarbij ik dan vanuit de index de call kan doen.
Als dat werkt dan kan ik gewoon eerst een simpele select statement gaan doen vanuit jquery naar de controller.

Echter is de DB connectie juist waar het niet loopt.
Ik krijg zowel via DBContext als via Membership de database niet aan de praat.
Ik zou EF Code First kunnen gebruiken, maar mijn voorkeur heeft een DB First aanpak.

Tribits schreef op dinsdag 03 februari 2015 @ 19:19:
Normaal gesproken zou ik naar Getting Started with ASP.NET MVC 5 verwijzen om een beetje thuis te raken in MVC5, leuke tutorial en mooi startpunt. Ik maak echter uit de topic start op dat je specifiek zit te worstelen met de authentication en authorization van de MVC applicatie. Daarover is de nodige informatie te vinden op deze site.

Specifiek wat betreft je opmerking over de database verbinding: als je een nieuwe MVC5 project aanmaakt wordt de userdata vanzelf al in de database opgeslagen. Het project wordt zo aangemaakt dat het framework daarvoor zelf de tabellen aanmaakt in de database waar ook de rest van je gegevens worden opgeslagen ("DefaultConnection"). Dit topic op stackoverflow geeft wel een aardige uitleg van hoe dat intern werkt. Specifiek je gebruikersnaam en wachtwoord hash belanden in een tabel genaamd AspNetUsers, kolommen UserName en PasswordHash. Zelf valideren lijkt me weinig zinvol, dit soort zaken zitten nu net in een framework om te voorkomen dat je het zelf moet implementeren maar vooral ook om te voorkomen dat je alle mogelijke gangbare (ontwerp)fouten maakt.

Die tutorial was ik inderdaad al doorgelopen, heb er al veel van opgestoken

Maar wat betreft EF alles voor mij laten doen, dat is helaas niet mijn manier van werken.
Ik wil zelf weten hoe het in elkaar steekt en het zelf kunnen opbouwen.
Daarnaast, als ik de default sets gebruik, persoonlijk vind ik dat niet prettig.
Graag maak ik zelf mijn database model, heeft ook als voordeel dat alles duidelijk is voor als er problemen zijn. _{want zal het uiteindelijk ook in mijn werk moeten toepassen}

Ben ondertussen ook hier doorheen aan het gaan, maar ook daarbij is het voornamelijk "Laat EF het maar lekker voor je doen".Maar als ik dat zou willen dan was ik wel met joomla aan de slag gegaan

[Woy]

tha_crazy schreef op woensdag 04 februari 2015 @ 11:23:
[...]
Echter is de DB connectie juist waar het niet loopt.
Ik krijg zowel via DBContext als via Membership de database niet aan de praat.
Ik zou EF Code First kunnen gebruiken, maar mijn voorkeur heeft een DB First aanpak.

Je noemt de hele tijd dingen die niet willen lukken, maar nergens WAT er niet wil lukken. De database aanspreken met EF is vrij eenvoudig ( Zowel Code First als DB First ). Uiteindelijk zal dat er ongeveer als volgt uitzien

C#:

using( var context = new MyDbContext() )
{
    var myEntries = context.MyTable.Where( x=> x.SomeProperty == "SomeValue );

    //TODO: Do something with entries
}

Verder haal je inderdaad veel te veel dingen door elkaar heen. EF heeft bijvoorbeeld niks met ASP.NET (MVC) te maken. Dus als je problemen met EF hebt, probeer die dan te isoleren, en los die op.

Je ASP.NET MVC problemen staan daar compleet los van. Een AJAX request doen gebeurt vanaf de client, en zal je dus in je view moeten oplossen ( .cshtml files ). Het daadwerkelijke opleveren van een resultaat van die AJAX call is weer een samenspel van de Model/View/Controller.

Belangrijkste tip: Splits je problemen vergenoeg op zodat je het kan overzien. Mocht je er dan nog niet uitkomen kun je een duidelijk overzichtelijk topic openen waar dan ook een beter antwoord op kan volgen

[D-Raven]

Wat bedoel je precies met het niet aan de praat krijgen van de database.
En hoezo EF alles voor je laten doen? EF is een ORM.
De tegenhanger van alles voor je laten doen zou dan dus zijn:
- Dat je zelf tabellen aanmaakt
- Zelf je update/insert/delete queries schrijft ("Select * from table where eigenwijs = 1")
- enz

Dit kan prima met MVC. Je bent niet verplicht om EF te gebruiken. Het is alleen dat het Identity framework standaard nogal verbonden is aan EF. Volgens mij is het wel mogelijk om hier een eigen datalaag onder te hangen.
Maar om het Identity framework te leren gebruiken, en tegelijk te leren hoe je hier een eigen datalaag onder hangt... Je maakt het jezelf niet makkelijk op deze manier.

[Tribits]

tha_crazy schreef op woensdag 04 februari 2015 @ 11:23:
Maar wat betreft EF alles voor mij laten doen, dat is helaas niet mijn manier van werken.
Ik wil zelf weten hoe het in elkaar steekt en het zelf kunnen opbouwen.
Daarnaast, als ik de default sets gebruik, persoonlijk vind ik dat niet prettig.
Graag maak ik zelf mijn database model, heeft ook als voordeel dat alles duidelijk is voor als er problemen zijn. _{want zal het uiteindelijk ook in mijn werk moeten toepassen}

Ben ondertussen ook hier doorheen aan het gaan, maar ook daarbij is het voornamelijk "Laat EF het maar lekker voor je doen".Maar als ik dat zou willen dan was ik wel met joomla aan de slag gegaan

Het gaat hier niet om het EF maar om ASP.NET Identity 2.0 en als je op die link klikt wordt eigenlijk al meteen duidelijk waarom je dit niet zelf moet willen programmeren. Het bevat enorm veel functionaliteit die sowieso enorm veel tijd zou vragen om zelf te programmeren, maar die bovendien nooit hetzelfde kwaliteitsniveau zou halen als je dat zelf zou bouwen. Het is dan haast onvermijdelijk dat je toegangscontrole allerlei kwetsbaarheden bevat en je website/applicatie zonder al te veel moeite gekraakt zal worden.

Ieder framework heeft als nadeel dat je er wat tijd in moet steken om het onder de knie te krijgen en dat je ook met de eigenaardigheden en tekortkomingen van het framework te maken krijgt. Dat zal voor ASP.NET identity niet anders zijn. Het biedt echter ruime mogelijkheden om te aan te passen en uit te breiden zodat het niet snel tekort zal schieten. Er zijn op het web de nodige artikelen daarover te vinden, maar omdat ik dat toch als geavanceerde technieken beschouw heb ik die informatie bewust maar even achterwege gelaten. Het integreren van het identity framework in je eigen applicatie is uitermate eenvoudig, daarover zijn genoeg voorbeelden te vinden. Al met al wegen de voordelen van het gebruik van de standaard functionaliteit ruimschoots op tegen de nadelen wat mij betreft.

Natuurlijk is het mogelijk om zelf een database verbinding op te zetten en je eigen authenticatie/autorisatie systeem te bouwen maar feitelijk ben je dan gewoon bezig een inferieure versie van ASP.NET entity 2 te schrijven. Of zoals een oud collega van me het verwoordde: "Dat ze allemaal het wiel opnieuw uit proberen te vinden is al vervelend, maar dat ze geheid met een ontwerp voor vierkante wielen komen maakt het pas echt problematisch".