Picking up ASP.NET Marvel vs. Capcom for data entry



  • Being in an ASP.NET Webforms shop, I have been advised by a couple friends (who do not work in Webforms shops) that this ancient* technology from 2002 won't be around for much longer, and that I should brush up my skills in a brand-new, spring chicken of a technology from 2009.

    Since the chances of my shop picking up MVC are pretty slim**, I figured I'd attempt to learn by applying it to a personal project to solve a legitimate problem: populating one type of data*** in the given database involves inserting into 10-20 tables, and it's getting to be a pain to hand-key the SQL to populate it. So, why not come up with a page or two to enter that data?

    So I head over to what Google thinks is probably the canonical tutorial to get started with a simple CRUD MVC application and start reading.

    After a few pages, I realize that I'm going to have to make a huge web of Models, Views and Controllers, with something about Routings and something about a querystring fetish, and then drop down and stick <<If I don't put this here the tr is invisible.>tr>'s together in a foreach loop to do something as simple as make a databound grid. For reference, the same grid can be done in Webforms like so:

    <asp:gridview ID="gvStuff" runat="server" DataSourceID="sdsAbilities" DataKeyNames="ability_id" AutoGenerateColumns="false">
                <Columns>
                    <asp:CommandField ShowEditButton="true" ShowHeader="true">                        
                    </asp:CommandField>
                    <asp:BoundField DataField="ability_id" HeaderText="ID" />                
                    <asp:BoundField DataField="ability_name" HeaderText="Name" />
                    <asp:BoundField DataField="ability_description" HeaderText="Description" />         
                    ...
                </Columns>            
            </asp:gridview>
            <asp:SqlDataSource ID="sdsAbilities" runat="server" ConnectionString="<%$ ConnectionStrings:DefaultConnection %>" SelectCommand="exec dbo.get_abilities" SelectCommandType="Text">
            </asp:SqlDataSource>
    

    Bam, suddenly I have a working grid, with zero code-behind! If I fill in a few more properties under the GridView and SqlDataSource, I add CUD to the CRUD. And that's just the first grid - all the child data in those 10-20 tables will probably require a custom edit form with cascading grids of their own.

    Is MVC the right tool for this job? Is there a better way to do this?


    *In the spirit of open-mindedness, I refrained from immediately reminding him that our industry is driven by idiotic fads, and has a bad habit of reinventing square wheels every few years.
    **If you're the only guy there who would have any knowledge of said technology, and you're not all that confident in it, it's irresponsible for you to be a champion for it.
    ***You'd be surprised at how complex the data structures become when you're storing information relating to RPG player character skills.



  • It's likely that neither are the right technology for the job. If you don't have to support ancient clients, then a client-side framework is the more "modern solution". We use Angular.js where I work and it gets the job done without too much hassle.

    Personally, I like Web Forms for most types of applications. I usually serve my Angular apps from Web Forms apps - and once you realize that you will never do a post-back, almost all of the complaints about Web Forms are no longer relevant.



  • @Jaime said:

    If you don't have to support ancient clients, then a client-side framework is the more "modern solution". We use Angular.js where I work and it gets the job done without too much hassle.

    Thanks, I'll look into that. There's no legacy support, this is just a quick and dirty app for me to use so I spend less time writing one-off INSERTs while keeping skills up-to-date.

    @Jaime said:

    Personally, I like Web Forms for most types of applications. I usually serve my Angular apps from Web Forms apps - and once you realize that you will never do a post-back, almost all of the complaints about Web Forms are no longer relevant.

    I've been working with Telerik/DevExpress controls, and the client-side APIs they offer seem to make for reasonably responsive and lightweight UI. This sounds like another way to get the best of both worlds.



  • Mvc is a routing and logic layer to give you more fine grain control over the end product. You sound like you're actually looking for the razor view engine which can be used to directly access the model and render to the page (or save back)

    Normal Web forms can do this to, the main difference is where things live.

    An example to output a table might be (written from mobile, so fuck formatting)

    <table>
    @{foreach(var item in list){
    <tr><td>@item.columnVar</td></tr>
    }
    </table>
    

    Which can be used to create display templates, forms, etc that are easy to include through partial html pages or served wholesale.

    Mvc is a methodology, and having had experience with both i highly prefer mvc, but Web forms are better if you're trying to keep complexity down for a perpetually SMALL application whose main purpose is business entry rather than customer appeal.

    *Note, razor can be used with Web forms or stand alone. It's just the default display for mvc projects. Razor is fucking sweet hot loving.



  • @Matches said:

    *Note, razor can be used with Web forms or stand alone. It's just the default display for mvc projects. Razor is fucking sweet hot loving.

    ... if you're still writing web apps that render the UI server-side. Most of us stopped doing that a few years ago.



  • @Groaner said:

    Bam, suddenly I have a working grid, with zero code-behind! If I fill in a few more properties under the GridView and SqlDataSource, I add CUD to the CRUD. And that's just the first grid - all the child data in those 10-20 tables will probably require a custom edit form with cascading grids of their own.

    That's the strength of WebForms. Throw together a competent little web app, as long as you're not too picky about how it looks and works.

    The weakness is when boss asks you to just change a little things here, or add a little box there. Once you find yourself digging into widget templates or going around the normal page cycle, it's time to throw away abstraction and drop down to the level of HTML. And that's where MVC comes in.



  • @cartman82 said:

    it's time to throw away abstraction and drop down to the level of HTML

    DataGrids support templates and WebForms have HTML controls that render as the exact HTML tags you specify. It's not necessary to throw away WebForm to get that level of control.

    Worst case, you could switch from a DataGrid to a Repeater. Then, you get pretty much the exact same model as a Razor foreach with a lot more binding options.

    <table>
    @{foreach(var item in list){
    <tr><td>@item.columnVar</td></tr>
    }
    </table>
    

    vs

    <asp:Repeater DataSourceID="sdsAbilities">
      <ItemTemplate><tr><td><%#Container.DataItem("columnVar")%></td></tr></ItemTemplate>
    </asp:Repeater>
    

  • Trolleybus Mechanic

    @Groaner said:

    Since the chances of my shop picking up MVC are pretty slim**

    I've worked in three .Net web development shops. All but one of them still had legacy "Classic VB" code as part of their systems, and were still in the process of converting to Web Forms only.

    I would hazard a guess at saying you're unlikely to find any****strong text established .Net shop switching to MVC. Unless you're writing a whole new version of the product from scratch AND your entire team is competent enough to be able to learn an entirely new framework and****strong text development methodology from scratch-- you're sticking with Web Forms.

    And honestly, web forms are kinda awesome.


    Filed under: Way fucking better than hand-coding every UI loop from scratch in php-- in vi, since there's no such thing as a usable IDE for php.


  • Trolleybus Mechanic

    editasreply: I just realized the MVC joke. I thought you were working on a RPG based on Marvel vs. Capcom.

    HAPPY FRIDAY!

    {checks calendar}

    fuck



  • @Lorne_Kates said:

    I would hazard a guess at saying you're unlikely to find anystrong text established .Net shop switching to MVC. Unless you're writing a whole new version of the product from scratch AND your entire team is competent enough to be able to learn an entirely new framework andstrong text development methodology from scratch-- you're sticking with Web Forms.

    It's probably going to take a massive leap in productivity in whatever new platform comes along to make a compelling case for a transition.

    @Lorne_Kates said:

    And honestly, web forms are kinda awesome.

    Viewstate et al. are dirty hacks, but those dirty hacks allow us to fake a stateful application over a stateless protocol. And Webforms doesn't necessarily force one to use viewstate.

    @Lorne_Kates said:

    I just realized the MVC joke. I thought you were working on a RPG based on Marvel vs. Capcom.

    A bunch of friends are serious fighting game players, so it's the first thing that comes to mind for that particular TLA.


Log in to reply