ASP.NET MVC en verschillende technieken / best practices.

[CodeCaster]

Dit topic is afgesplitst van De Devschuur Coffee Corner - Iteratie 2

---

Volgens mij ben ik gisteren met een misconceptie begonnen aan MVC. Ik vind het Model te dik, die zou wat mij betreft zo min mogelijk en zo mogelijk zelfs helemaal niets van de database moeten weten. De wizards die in Visual Studio worden geïnstalleerd gaan er echter van uit dat je Model automatisch een Entity is. Aangezien ik tegelijk met Code First ben begonnen (voorheen altijd Database First), zie ik dus nog niet hoe ik viewspecifieke properties aan m'n Model kan toevoegen, omdat dat dan automatisch kolommen worden... De consensus is dan "gooi maar in je ViewBag", en dat vertik ik.

Vanavond weer verder hobbyen, misschien eerst maar eens een boek oppikken in plaats van trial&error.

[ Voor 23% gewijzigd door Janoz op 06-11-2012 13:42 ]

[Down]

CodeCaster schreef op dinsdag 06 november 2012 @ 10:21:
[...]

---

Volgens mij ben ik gisteren met een misconceptie begonnen aan MVC. Ik vind het Model te dik, die zou wat mij betreft zo min mogelijk en zo mogelijk zelfs helemaal niets van de database moeten weten. De wizards die in Visual Studio worden geïnstalleerd gaan er echter van uit dat je Model automatisch een Entity is. Aangezien ik tegelijk met Code First ben begonnen (voorheen altijd Database first), zie ik dus nog niet hoe ik viewspecifieke properties aan m'n Model kan toevoegen, omdat dat dan automatisch kolommen worden... De consensus is dan "gooi maar in je ViewBag", en dat vertik ik.

Vanavond weer verder hobbyen, misschien eerst maar eens een boek oppikken in plaats van trial&error.

Je kunt met T4 templates i.c.m. met de Fluent API toch gewoon schone POCO's genereren? Al gekeken naar Entity Framework Powertools?

[CodeCaster]

Down schreef op dinsdag 06 november 2012 @ 10:23:
[...]


Je kunt met T4 templates i.c.m. de Fluent API toch gewoon schone POCO's genereren?

What what whaaat?

Al gekeken naar Entity Framework Powertools?

Nope, dat zal ik eens doen. Ik doe te veel onderhoud en te weinig nieuwbouw, vandaar dat ik dus vanaf scratch wil beginnen met een paar technieken die ik nog niet geheel beheers. Vandaar ook MVC 4 en EF 5 Code First. Maar dat zeg ik: eerst maar eens lezen wat het nu daadwerkelijk kan, en hoe het "moet".

[cvs79]

CodeCaster schreef op dinsdag 06 november 2012 @ 10:21:
[...]

---

Volgens mij ben ik gisteren met een misconceptie begonnen aan MVC. Ik vind het Model te dik, die zou wat mij betreft zo min mogelijk en zo mogelijk zelfs helemaal niets van de database moeten weten. De wizards die in Visual Studio worden geïnstalleerd gaan er echter van uit dat je Model automatisch een Entity is. Aangezien ik tegelijk met Code First ben begonnen (voorheen altijd Database First), zie ik dus nog niet hoe ik viewspecifieke properties aan m'n Model kan toevoegen, omdat dat dan automatisch kolommen worden... De consensus is dan "gooi maar in je ViewBag", en dat vertik ik.

Vanavond weer verder hobbyen, misschien eerst maar eens een boek oppikken in plaats van trial&error.

Is het niet beter om het model van mvc te zien als het viewmodel. Dan kun je nog steeds een los model gebruiken voor je database model. Deze staan dus helemaal los van elkaar.

[Down]

CodeCaster schreef op dinsdag 06 november 2012 @ 10:31:
Nope, dat zal ik eens doen. Ik doe te veel onderhoud en te weinig nieuwbouw, vandaar dat ik dus vanaf scratch wil beginnen met een paar technieken die ik nog niet geheel beheers. Vandaar ook MVC 4 en EF 5 Code First. Maar dat zeg ik: eerst maar eens lezen wat het nu daadwerkelijk kan, en hoe het "moet".

In principe kun je met T4 templates bepalen hoe je iets genereert aan de hand van je model. Nu zit dat ingebakken in EF Power Tools. Kun je vanuit je contextmenu de 'code first' code genereren. Je kunt zelf ook nog de templates reverse engineeren.

In principe kun je met een paar clicks complete schone POCO's genereren

[CodeCaster]

cvs79 schreef op dinsdag 06 november 2012 @ 10:35:
[...]


Is het niet beter om het model van mvc te zien als het viewmodel. Dan kun je nog steeds een los model gebruiken voor je database model. Deze staan dus helemaal los van elkaar.

Dat probeer ik dus, maar dat vinden de wizards die MVC 4 installeert niet goed. Die kijken of het Model een Entity is, en zo niet dan klapt de boel eruit en wordt er geen controller aangemaakt. Ik kan niet kiezen voor een "gewoon" model, alleen entitites. Misschien moet ik ook gewoon m'n addons eens bijwerken.

Ik had juist met die insteek een apart Entities-project gemaakt met daarin m'n POCO's waaruit tabellen gegenereerd moeten worden en een DbContext. Want ik wil helemaal geen databasezooi in m'n MVC-project. Die DbContext kan ik vanuit (de) MVC(-wizards) echter niet aanspreken (en ja, er ligt uiteraard een reference).

Maar dat zeg ik: ik moet eerst nog maar eens wat lezen.

D-Raven schreef op dinsdag 06 november 2012 @ 10:39:
[...]


Gewoon niet je model als viewmodel gebruiken en een aparte viewmodel definieren.

Maar de wizards!1!11

[ Voor 13% gewijzigd door CodeCaster op 06-11-2012 10:40 ]

[D-Raven]

CodeCaster schreef op dinsdag 06 november 2012 @ 10:21:
[...]

---

Volgens mij ben ik gisteren met een misconceptie begonnen aan MVC. Ik vind het Model te dik, die zou wat mij betreft zo min mogelijk en zo mogelijk zelfs helemaal niets van de database moeten weten. De wizards die in Visual Studio worden geïnstalleerd gaan er echter van uit dat je Model automatisch een Entity is. Aangezien ik tegelijk met Code First ben begonnen (voorheen altijd Database First), zie ik dus nog niet hoe ik viewspecifieke properties aan m'n Model kan toevoegen, omdat dat dan automatisch kolommen worden... De consensus is dan "gooi maar in je ViewBag", en dat vertik ik.

Vanavond weer verder hobbyen, misschien eerst maar eens een boek oppikken in plaats van trial&error.

Gewoon niet je model als viewmodel gebruiken en een aparte viewmodel definieren.

Ik gebruik overigens MVC icm entity framework bijna nooit. Vind de autogegenereerde templates e.d. maar niks en heb weinig zin om zelf daar templates voor te bouwen.
Gebruik zowiezo voornamelijk nhibernate

[ Voor 10% gewijzigd door D-Raven op 06-11-2012 10:41 ]

[GateKeaper]

CodeCaster schreef op dinsdag 06 november 2012 @ 10:21:
[...]
..zie ik dus nog niet hoe ik viewspecifieke properties aan m'n Model kan toevoegen, omdat dat dan automatisch kolommen worden... De consensus is dan "gooi maar in je ViewBag", en dat vertik ik.

Niet in je ViewBag gooien, hier zit het verschil tussen een EF Model (database model, je poco class) en je ViewModel.

Ik probeer mijn EF Models (ook code first) gewoon 100% poco te houden, zodat ze 1:1 mappen naar mijn database table. Heb je byzondere dingen nodig in je View, of een beperkte variant van je model, dan map je de boel naar een ViewModel. Dit doe ik in mijn controller.

Daarbij kan je gebruik maken van Automapper of je maakt in je service gebruik van lambda's om te mappen. "dbcontext.Comments.Select(x => x).Project().To<CommentTitles>();

Al ben ik even kwijt of die Project.To één van mijn eigen extentions is, of dat het wel in EF / Linq zit. Kan zo de juiste termen in Google niet meer vinden. Kan ik vanavond wel even uitzoeken voor je, mocht dat gewenst zijn.

Gevonden (lang leven tfspreview.com). http://www.devtrends.co.u...-in-your-data-access-code.

En wil je wel meer info dirty in je model hebben. Dan kan je je property laten ignoren met een [Ignore] attribuut of in fluent syntax met Entity<Comment>().Ignore(t => t.FullName);

[ Voor 11% gewijzigd door GateKeaper op 06-11-2012 10:48 ]

[D-Raven]

GateKeaper schreef op dinsdag 06 november 2012 @ 10:41:
[...]


Niet in je ViewBag gooien, hier zit het verschil tussen een EF Model (database model, je poco class) en je ViewModel.

Ik probeer mijn EF Models (ook code first) gewoon 100% poco te houden, zodat ze 1:1 mappen naar mijn database table. Heb je byzondere dingen nodig in je View, of een beperkte variant van je model, dan map je de boel naar een ViewModel. Dit doe ik in mijn controller.

Daarbij kan je gebruik maken van Automapper of je maakt in je service gebruik van lambda's om te mappen. "dbcontext.Comments.Select(x => x).Project().To<CommentTitles>();

Al ben ik even kwijt of die Project.To één van mijn eigen extentions is, of dat het wel in EF / Linq zit. Kan zo de juiste termen in Google niet meer vinden. Kan ik vanavond wel even uitzoeken voor je, mocht dat gewenst zijn.

Gevonden (lang leven tfspreview.com). http://www.devtrends.co.u...-in-your-data-access-code

Ik ben wel geintereseerd in die Project.To extensions. Gebruik nu ook Automapper (tip: als je model en viewmodel 1op1 hetzelfde zijn, kun je DynamicMap gebruiken, dan hoef je geen mapping config ervoor te definieren).

edit; ninja edit
En ik te lang gewacht met posten

[CodeCaster]

D-Raven schreef op dinsdag 06 november 2012 @ 10:39:
[...]

Gewoon niet je model als viewmodel gebruiken en een aparte viewmodel definieren.

GateKeaper schreef op dinsdag 06 november 2012 @ 10:41:
[...]

Niet in je ViewBag gooien, hier zit het verschil tussen een EF Model (database model, je poco class) en je ViewModel. [...] Heb je byzondere dingen nodig in je View, of een beperkte variant van je model, dan map je de boel naar een ViewModel. Dit doe ik in mijn controller.

Ah. Ik neem aan dat deze principes in degelijke boeken (zoals Haan in "De Devschuur Coffee Corner - Iteratie 2", Professional ASP.NET MVC 4) worden uitgelegd? Want wat ik in het gros van de tutorials en blogs kan lezen, kan ik zelf ook wel bedenken.

[ Voor 6% gewijzigd door CodeCaster op 06-11-2012 11:17 ]

[GateKeaper]

CodeCaster schreef op dinsdag 06 november 2012 @ 11:16:

Ah. Ik neem aan dat deze principes in degelijke boeken (zoals Haan in "De Devschuur Coffee Corner - Iteratie 2", Professional ASP.NET MVC 4) worden uitgelegd? Want wat ik in het gros van de tutorials en blogs kan lezen, kan ik zelf ook wel bedenken.

Geen idee eigenlijk. Ik programmeer op de logica van mijn boeren verstand, en zo nu en dan eens een blog / channel9 filmpje.

[D-Raven]

GateKeaper schreef op dinsdag 06 november 2012 @ 11:27:
[...]


Geen idee eigenlijk. Ik programmeer op de logica van mijn boeren verstand, en zo nu en dan eens een blog / channel9 filmpje.

Dat inderdaad.

Waar ik een tijdje geleden tegenaanliep: http://www.paulstovell.com/clean-aspnet-mvc-controllers
Wel interesant idee, moet alleen nog eens een tryout projectje maken, om te kijken hoe dit werkt als je complexere dingen gaat doen.

[CodeCaster]

GateKeaper schreef op dinsdag 06 november 2012 @ 11:27:
[...]

Geen idee eigenlijk. Ik programmeer op de logica van mijn boeren verstand, en zo nu en dan eens een blog / channel9 filmpje.

Ik ook, maar dan helpt het dus niet als de IDE je in een stramien duwt dat niet bij je ideeën past.

D-Raven schreef op dinsdag 06 november 2012 @ 11:42:
[...]

Waar ik een tijdje geleden tegenaanliep: http://www.paulstovell.com/clean-aspnet-mvc-controllers
Wel interesant idee, moet alleen nog eens een tryout projectje maken, om te kijken hoe dit werkt als je complexere dingen gaat doen.

Dat ziet er ook goed uit ja.

[GateKeaper]

CodeCaster schreef op dinsdag 06 november 2012 @ 11:46:

Ik ook, maar dan helpt het dus niet als de IDE je in een stramien duwt dat niet bij je ideeën past.

ReSharper heeft mij geholpen om meer linq/lambda's te gaan gebruiken. Weg met de korte foreach's, welkom lambda's! Daar kon ik wel mee leven . Voor de rest hanteer ik het principe, als ik ook maar enigzins het gevoel heb dat ik teveel werk doe, of dat iets makkelijker moet kunnen, dan wordt het tijd om op onderzoek uit te gaan .

Ik kijk er dan ook niet tegenop om gewoon 2 avonden lang (zeg 2x 4/5 uur) gewoon op internet rond te zoeken naar allerlei oplossingen voor mijn 'probleem'. De eerste beste SO question met geaccepteerd antwoord neem ik niet automatisch ook aan als zijnde mijn antwoord (tenzij hij erg bevredigend is).

Kwestie van veel research doen, en inderdaad niet blind uitgaan van 1 blog, maar meerdere blogs lezen en je eigen conclusie trekken, en dan kom je een heel eind.

Wellicht dat boeken je dezelfde stof sneller kunnen overbrengen, maarja... dan is het maar weer net afhankelijk van de kijk die het boek je er op geeft. Dan word je dus in zekere zin in "het stramien" van de auteur geduwt. Bij blogs krijg je meerdere stramienen aangereikt, en kies/bepaal ik vervolgens mijn eigen.

Dat is trouwens ook waarom ik die Channel9 filmpjes gewoon erg interessant en leerzaam vind. Die lui die bouwen soms in 5 minuten tijd functionaliteiten waarbij ik het gevoel krijg iets gemist te hebben. Erg leerzaam om dan even terug te spoelen en de pauze knop te gebruiken om te zien hoe ze in 10 regels code een werkend proof of concept hebben van bijvoorbeeld een werkende web api gebaseerd op OData.

Boeken zijn niet echt mijn ding. Heb wel eens een paar digitaal doorgebladerd, maar toen had ik ook al snel het gevoel van "skip, skip, skip.. oooh, interessant... o nee, skip..."

[Devilly]

GateKeaper schreef op dinsdag 06 november 2012 @ 11:57:
Boeken zijn niet echt mijn ding. Heb wel eens een paar digitaal doorgebladerd, maar toen had ik ook al snel het gevoel van "skip, skip, skip.. oooh, interessant... o nee, skip..."

Persoonlijk vind ik boeken juist erg fijn. Ik kan daarmee in alle rust de stof doorwerken, zonder aan het tempo van de verteller vast te zitten. Natuurlijk kun je een filmpje pauseren, maar om bepaalde uitleg nogmaals te horen, moet je het juiste punt opzoeken, luisteren en vervolgens in de repeat gaan totdat je het helemaal snapt. Bij een boek is het: lees, lees, lees... ik snap het niet, even terug kijken (blijven kijken, blijven kijken)... ik kan weer verder.

[.Gertjan.]

Devilly schreef op dinsdag 06 november 2012 @ 12:26:
[...]


Persoonlijk vind ik boeken juist erg fijn. Ik kan daarmee in alle rust de stof doorwerken, zonder aan het tempo van de verteller vast te zitten. Natuurlijk kun je een filmpje pauseren, maar om bepaalde uitleg nogmaals te horen, moet je het juiste punt opzoeken, luisteren en vervolgens in de repeat gaan totdat je het helemaal snapt. Bij een boek is het: lees, lees, lees... ik snap het niet, even terug kijken (blijven kijken, blijven kijken)... ik kan weer verder.

Ik vind beide eigenlijk wel fijn. Van een filmpje is het voordeel dat je het werkend ziet, een boek is wat abstracter. Over het algemeen programmeer ik namelijk niet mee als ik met een boek of filmpje bezig ben.

Een boek heeft overigens wel als voordeel dat het zich beter leent voor bepaalde concepten. Architectuur is gewoon te lastig om in spreektaal goed uit te leggen en leent zich dus beter voor een boek.

Momenteel ben ik bezig in het boek over Enterprise Architecture (taaie stof overigens) en moet er niet aan denken dit via screencasts geleerd te krijgen. Wat wel leuk is aan het boek is dat ik de mogelijke oplossingen die ze noemen allemaal wel een keertje heb gebouwd de afgelopen jaren. Ik merk dat mijn visie op architectuur de afgelopen jaren nog wel eens wil wisselen. Gelukkig bevestigt het boek dat ik nooit een slechte opzet heb gebruikt, maar gewoon een andere benadering had die in principe net zo goed is


Vandaag voor het eerst in lange tijd weer eens een "complexe technische uitdaging" Voor een projectje moet ik een soort "query" ondersteunen waarin de klant een aantal teksten kan filteren op basis van een ingevoerde query. Best lachen, zelf een beetje die query uit elkaar trekken enzo

[BikkelZ]

Ik zag dat er wat afgesplitst was. Ik had in het koffietoppik de volgende vraag neergezet over MVC:

"Ik ben een beetje rond aan het kijken om een eerste van-de-grond-af-aan ASP.Net MVC testprojectje op te zetten om eens wat te gaan stoeien voordat ik aan een echt project ga beginnen. Als ORM wil ik gewoon entities of misschien toch LLBLGen gaan gebruiken, maar qua CMS kom ik er nog niet echt uit. Is er een manier waarop een "gebruiker" (niveau gemiddelde webmaster, maar waarschijnlijk ik zelf) via bijvoorbeeld spark-achtige templates met View-data aan de slag kan? Ik vond spark op zich goed genoeg werken maar volgens mij moet ik dan wel iedere keer een update doen en daar ben ik te lui efficient voor."

[D-Raven]

Ik snap je vraag niet, hoezo CMS ?? Je gaat beginnen met een vanaf de grond af aan project in asp.net mvc.. Hoezo heb je het dan ineens over een CMS ?

Overigens, ik vond spark ook wel goed werken, maar toen ik eenmaal Razor ben gaan gebruiken heb ik nooit meer terug gekeken.

[D-Raven]

Een redelijk onbekende methode op een Controller is: TryUpdateModel.

Wat is hier handig aan? Je kunt handmatig modelbinding doen op een model entiteit. Dus in plaats van dat je het als parameter in je ActionMethod opneemt ben je in staat om het te delegeren naar andere componenten.

Je kunt dan dingen doen als:

C#:

//in een controller action method
var model = new MyModel();
TryUpdateModel(model, "", new string[] { "Property1", "AnotherProperty", "SomeOtherProperty" });

De lege string is als placeholder voor de prefix parameter. Deze kun je gebruiken als je bijvoorbeeld een ViewModel hebt welke meerdere componenten in zich heeft. Als je de DisplayFor/EditorFor extensies gebruikt dan zal MVC de namen van de inputs prefixen met de variabele naam van je component.
De prefix string parameter kun je dan gebruiken om de modelbinding te scopen op zo'n component.

[RobIII]

^ Wel even goed de remarks en security note lezen (i.v.m. over/under posting).

[D-Raven]

RobIII schreef op woensdag 07 november 2012 @ 17:12:
^ Wel even goed de remarks en security note lezen (i.v.m. over/under posting).

Ah inderdaad. Vandaar dat ik ook die white list van properties meegaf.

[Haan]

D-Raven schreef op woensdag 07 november 2012 @ 17:05:
Een redelijk onbekende methode op een Controller is: TryUpdateModel.

Wat is hier handig aan? Je kunt handmatig modelbinding doen op een model entiteit. Dus in plaats van dat je het als parameter in je ActionMethod opneemt ben je in staat om het te delegeren naar andere componenten.

Je kunt dan dingen doen als:

C#:

//in een controller action method
var model = new MyModel();
TryUpdateModel(model, "", new string[] { "Property1", "AnotherProperty", "SomeOtherProperty" });

De lege string is als placeholder voor de prefix parameter. Deze kun je gebruiken als je bijvoorbeeld een ViewModel hebt welke meerdere componenten in zich heeft. Als je de DisplayFor/EditorFor extensies gebruikt dan zal MVC de namen van de inputs prefixen met de variabele naam van je component.
De prefix string parameter kun je dan gebruiken om de modelbinding te scopen op zo'n component.

Maar hoe is dit dan precies handig? Ik kwam deze functie laatst ook voor het eerst tegen, maar kon niet echt een reden verzinnen waarom je het zou gebruiken. Het handmatig gaan binden mbv strings lijkt me ook niet echt ideaal, wat als je model uit tien, of twintig, of nog meer properties bestaat? Om nog maar te zwijgen over het wijzigen van property namen.

[D-Raven]

Het zet de deur open om je viewmodel door verschillende componenten af te laten handelen. Stel dat je een vrij complexe view hebt. Als je view dan is opgebouwd uit verschillende componenten zou je zoiets als dit kunnen doen.

C#:

var componentModel = new MySpecificComponentModel();
TryUpdateModel(componentModel, "componentNaam");

Dus in plaats van dat je alles in een keer naar een groot viewmodel terugbind, en deze gaat rond pasen door je verschillende componenten, kun je ieder component zelf zijn data laten binden.

edit:

Orchard gebruikt dit tot in het extreme. Wat zij doen icm met Clay is een semi dynamic viewmodel bouwen.

Dit viewmodel gaat dan door een infrastructuur heen, welke dynamisch componenten aan dit model toevoegt. Vervolgens gaat dit model de view in, en word ieder component in dat model gerenderd.
Als er dan een POST geplaatst wordt kunnen ze zo de data van ieder component weer terug halen.

edit2:

Overigens mbt het handmatig binden met strings. Je bind hiermee niks heh, je geeft een whitelist van geldige properties terug. Dit HOEF je niet te gebruiken, sterker nog ik gebruik het _nooit_ ik bind altijd terug naar een ViewModel welke alleen de geldige properties heeft, op deze manier heb ik ook een "white list" alleen zonder de strings .

Het mappen van mn viewmodel naar mn entiteit doe ik zelf wel. Ik moet hier vaak toch een vertaalslag maken.

[ Voor 50% gewijzigd door D-Raven op 13-11-2012 09:54 ]

[Haan]

Interesse materie, net de eerste twee blogs over Clay gelezen, dat is wel mooi spul wat in een CMS inderdaad behoorlijk handig zal zijn.

[D-Raven]

Haan schreef op dinsdag 13 november 2012 @ 09:59:
Interesse materie, net de eerste twee blogs over Clay gelezen, dat is wel mooi spul wat in een CMS inderdaad behoorlijk handig zal zijn.

Zekers. Ik ken de source van orchard redelijk goed. Er zitten een hoop dingen in die erg interesant zijn ook voor normale MVC projecten.
Zoals een manier om autofac te gebruiken om een 'environment' te creeeren waarin je request wordt afgehandeld. Zodat je met behulp van shims voor de httpcontext e.d. deze zelfde manier kan gebruiken om een environment instantie te starten buiten de context van een httprequest.
Dit is ideaal als je werk wilt doen buiten de default asp.net pipeline, zoals in een task scheduler achtige implementatie, of via een console app.

[CodeCaster]

Ik heb de afgelopen dagen nog maar eens een avondje of wat geknutseld om te kijken of ik het een en ander begrijp. Ik heb nu dit:

Model:

C#:

public class Contact : GenericIdentifyableEntity<Contact>
{
    [Required]
    [StringLength(100, MinimumLength = 3, ErrorMessage = "The {0} must be at least {2} characters long.")]
    public String CompanyName { get; set; }

    [GenericNavigation]
    public Address Address { get; set; }

    [NotMapped]
    [ScriptIgnore]
    public int RemoveMeViewFieldFoo { get; set; }
}

DataAccess ((View)Model aan entity(/ies) koppelen)

C#:

public class ContactAccess : GenericDataAccess<Contact>
{
    private MyContext _context = null;
    public ContactAccess(MyContext context)
        : base(context)
    {
        _context = context;
    }

    protected override void BeforeSave(Contact contact)
    {
        contact.Address.CreateOrUpdate(_context, false);
    }

    protected override void BeforeDelete(Contact contact)
    {
        contact.Address.Delete(_context, false);
    }
}

Controller:

C#:

public class ContactsController : GridCrudController<Contact>
{
    public ContactsController() : this(new MyContext()) { }

    public ContactsController(MyContext context)
        : base(context)
    {
        this.DataAccess = new ContactAccess(context);

        this.GridModel.Prefix = this.GridModel.Caption = "Contacts";
    }
}

View:

HTML:

@model CodeCaster.MVC.Data.Model.JqGridModel
@{
    ViewBag.Title = "Contacts";
}

@section Head
{  
    @{ Html.RenderPartial("~/Views/Shared/Grid/jqGridHeadPartial.cshtml"); }
 
    <script type="text/javascript">
        var colNames = ['Company name', 'Address', 'Zip code', 'Location', 'Operations'];
        var colModel = [
                { name: 'CompanyName', index: 'CompanyName', width: 120 },
             { name: 'Address.AddressString', index: 'Address.AddressString', width: 200 },
             { name: 'Address.Zipcode', index: 'Address.Zipcode', width: 60 },
             { name: 'Address.LocationString', index: 'Address.LocationString', width: 200 },
                { name: 'ID', formatter: createOperationsLinks, width: 200 },
        ];
    </script>
}

<h2>Contacts</h2>
<p>@Html.ActionLink("Create New", "Create")</p>

@{ Html.RenderPartial("~/Views/Shared/Grid/jqGridPartial.cshtml"); }

En dat ziet er dan zo uit:



Verder voorziet de controller, dankzij een generieke base-implementatie, in CRUD-operaties voor het opgegeven Model. Daarnaast heeft die controller een JSON-feed van alle entities, die door het grid wordt aangesproken. Op deze manier kan ik eenvoudig en snel CRUD-schermen bouwen voor generieke models, terwijl het geheel uitbreidbaar blijft voor models en views die meer vereisen.

Mijn vraag in eerste instantie ging over de koppeling tussen het viewmodel en het entity model, maar ik geloof dat ik dat met mijn DataAccess voorlopig heb opgevangen (ik vind dat data ophalen en koppelen helemaal geen controller-werk, een controller mapt URL's naar acties die mogelijk iets met data doen, als dat het geval is dan spreken ze de DataAccess aan).

Als ik nu een niet-generiek viewmodel nodig heb (dat wil zeggen: een viewmodel dat níet één-op-één mapt naar een databasetabel), creëer ik een DataAccess voor dat model waarin ik de (hier niet zichtbare) LoadAll(), CreateOrUpdate() en Delete() override en (bijvoorbeeld middels AutoMapper) een koppeling maak tussen de viewdata en de databasedata.

Over de naamgeving van sommige elementen ben ik nog niet tevreden, dat komt nog wel als ik hiermee verder ga. Ik begrijp de basis nu in ieder geval iets beter.

Voel je vrij dit ontwerp te bekritiseren.

[ Voor 7% gewijzigd door CodeCaster op 15-11-2012 10:30 ]

[Haan]

Het is in ieder geval heel anders dan ik zelf zou doen, maar ik ben er nog niet uit of dat goed of slecht is

Wat doen die [NotMapped] en [ScriptIgnore] die je in je model gebruikt? Heb je die zelf gemaakt, want het zijn volgens mij geen standaard attributes?

[CodeCaster]

Voor wat Entity Framework betreft zijn mijn models wel entity models, zodra ik ze als DbSet<Model> toevoeg aan mijn context.

Als ik dan stiekem toch een viewspecifiek veld aan een generiek (1-op-1-)model wil toevoegen, gebruik ik [NotMapped], een attribute uit Entity Framework 5, wat ervoor zorgt dat de gemarkeerde property niet als kolom wordt aangemaakt in je database.

De zo gemarkeerde property kan ik dan vanuit mijn Controller, DataAccess en View wel aanspreken, bijvoorbeeld voor een lijstje met keuze-opties voor een dropdown.

[ScriptIgnore] (MSDN) zorgt voor hetzelfde effect, maar dan richting de JSON-feed, wat in sommige gevallen ook wenselijk kan zijn.

Maar vertel, hoe zou jij het doen?

[ Voor 15% gewijzigd door CodeCaster op 15-11-2012 10:34 ]

[Haan]

Ah dat had ik zelf kunnen bedenken dat het uit EF komt (ik kan dat meestal niet gebruiken, omdat ik alles via een webservice moet doen).
Maar is het niet zo dat de entity classes partial zijn, waardoor je gewoon extra properties in je eigen partial Contact class kan zetten, zonder dat invloed heeft op database kolommen?

[CodeCaster]

Ik kon de documentatie van die NotMapped ook lastig vinden. Vanaf .NET 4.5 zit hij in het framework.

Maar partials gaan hier niet helpen, want EF Code First met POCO's werkt in runtime. Partial classes worden compile-time al bij elkaar geraapt, dat onderscheid is in runtime dus weg.

Een alternatief voor de aanpak met attributes is whitelisting, waarbij ik met de door * Down aangegeven fluent mapping properties kan mappen aan kolommen. Hier voel ik minder voor dan voor blacklisting middels deze attributen, maar wanneer ik specifiekere mappings nodig ga hebben ga ik hier zeker nog naar kijken.

[Down]

Ik hecht persoonlijk meer waarde aan schone POCO's die niet door attributen zijn vervuild. Daarbij wordt die whitelisting met 2 clicks (give or take) voor je gegenereerd en dus erg makkelijk te wijzigen. En blacklisting vind ik daarbij nog eens behoorlijk minder éénduidig.

Maar goed, je kunt aardig wat kanten op

[D-Raven]

@CodeCaster ik heb in spirit dezelfde verdeling van verantwoordelijkheden. Alleen heb ik het zo opgezet dat wat jij je DAO noemt (DataAccess) noem ik een MapperService. Daarnaast neemt de controller alleen een afhankelijkheid op deze MapperService en heeft deze geen weet van whatever de data vandaan komt.

De MapperService weet precies welke data hij nodig heeft om een bepaalde viewmodel te genereren. Dus hij neemt de afhankelijkheid op je datacontext, webservice, of waar ook je data vandaan komt.

En ik sluit me aan bij Down, ik vind attributes op mn (data)model ook maar niks. Heb zelf sterk de voorkeur voor schone POCO's. Mijn mapperservice weet hoe en welke properties er gemapped moeten worden.

Edit:

Vond vandaag weer iets nieuws. Namelijk GetDependencyScope op de HttpRequestMessage.

Stel dat je met IoC een component geregistreerd hebt dat deze per request gescoped is.

C#:

 public class MyActionFilter : ActionFilterAttribute
    {
        public override void OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
        {
           //Dit is niet gescoped op request, je krijgt hier dus een nieuwe instantie terug
            var myComponent = GlobalConfiguration.Configuration.DependencyResolver.GetService(typeof(IMyComponent)) as IMyComponent;
            //gescoped op de huidige request, indien dit component in deze request al een keer geresolved is, dan krijg je deze terug, anders een nieuwe instantie.
            var myComponent = actionExecutedContext.Request.GetDependencyScope().GetService(typeof(IMyComponent)) as IMyComponent;
           

        }
    }

Niet dat ik veel van dit soort dingen doe in actionfilters, maar het is goed om te weten dat je, mits je DI container dit ondersteund, deze mogelijkheid hebt. Je kunt ook property injection gebruiken als je een custom actionfilterprovider registreert. Autofac heeft hier bv voorzieningen voor.

[ Voor 46% gewijzigd door D-Raven op 16-11-2012 12:31 ]

[CodeCaster]

Maar goed, je kunt aardig wat kanten op

Behoorlijk, ja. Bedankt voor jullie bijdragen.

Het "framework" dat ik aan het bouwen ben tussen mijn applicatie en ASP.NET MVC om die laatste beter te leren begrijpen, gaat aardig op ASP.net Awesome - jQuery Ajax Controls (waar ik vanavond op stuitte) lijken. De mijne is niet zo flashy met jQuery (die staat voor hierna op de lijst...), maar de standaardzaken als JSON-grids (middels jqGrid), (multi)lookupboxen en weet ik wat met eigen controllers had ik ook al geïmplementeerd, of in ieder geval de logica voor opgebouwd.

Een licentie voor die library van ze kost € 200, misschien toch maar overwegen. Je mag vast wel eerst wat tegen de library bouwen die bij de demo zit, dan maar geen source. Als het dan bevalt en ik ga het ooit inzetten, betaal ik wel.

[ Voor 3% gewijzigd door CodeCaster op 28-11-2012 22:40 ]