Been a hectic first two weeks on the job! Seven days in, we have agreement on our first set of entities – and have seeded it with data and some sprocs to generate manufacturing work orders and assembly history. Now comes the fun part – the UI!
Big challenge here – we are under extreme pressure to deliver in a short time frame a fairly smooth and intuitive UI. Since I work on a manufacturing floor, the design needs to be responsive and work naturally on a tablet and with handheld scanners.
And since whatever we produce will almost certainly undergo massive changes, it needs to be lightweight and easy to implement. In terms of design, I’m caught here between two demands – it needs to be throwaway code, yet intuitive and well designed enough to warrant a second version when we get our data layer more complete. What to do?
I’m going to skip some of the steps we followed last week in putting together. Here’s the nitty-gritty on how we scaffolded out the administrative forms to add new records to the workflow template tables (like Process, Step, etc).
- Make sure your data layer is set up in SQL Server, including all relational ties and identity fields and FK’s. Ensure that you have a SQL server login you can use for application access with limited rights (I usually grant db_reader, db_write role access to the database).
- If you haven’t already, install Visual Studio 2013 and create new project. With the new One ASP.Net there’s no separate MVC or Webform project options, thank GAWD. So, just select File, New Project, and select ASP.NET Web Application.
- Add a new data model. Right click on the Model folder, and select Add new -> ADO.Net Entity Data Model. Add all the tables you want to connect to.
Right click on Controllers, and select Add new Scaffolded Item. Select the MVC5 Controller with Views, using Entity Framework option.
NOTE – here I got an error “blah blah blah… Error generating the model, etc.” the big hint is at the end of the error message – “TRY REBUILDING THE PROJECT”! VS is having a hard time understanding the generated code classes from EF and is waiting on you to hit F5. Build the project and you should be golden.
See the screenshot below from my model. I’m going to try to build out a scaffolded Process view, a Location view, and a Step view. The Step view in particular should have dropdowns to Test (which is off the screen) and the StepType lookup table. Let’s rock:
Now to scaffold out my actual application layer itself. I just want to add three forms, one for Process, one for Location, and the last one for Step. Don’t be intimidated if you’re coming from the webforms world – think of the Views as being forms, and the Controller folders as just being a handy place to stuff your actions where we used to put in codebehind or inline code.
- Right click on the Controller and select Add -> New Scaffolded Item. Select the MVC 5 Controller with Views using EF option.
Then fill it in with the name of your entity – like “ProcessController” – and select the model class and the data context class you created with your model earlier:
Now check out the view in SolutionExplorer. Hmm, this is interesting. Not only do I get shiny awesome controller scripting – all my business logic in one shiny beautiful place! – but now I see some views appearing as well. Wonder what these do?
- Lets build it, and enter in my URL – replacing “default.aspx” with “Process” for example. Wow! A nice list view here appears of processes. Clicking on the Edit hyperlink gets me this fancy Razor view:
Its ugly, no doubt – but I can change that easily using Bootstrap, and it’s responsive design. I can easily hide the modified/create fields in the cshtml views so only the important fields are shown.
- Now go through and add new scaffolded items for Location and Step. However, I see an issue – ProductType isn’t showing up where it should.
- Closing out the browser, I open up the entity framework diagram and immediately see the issue – ProductType in my data model is linked to the Step entity – not the Process model as it should be. (The list of locations is fixed – but each ProductType has a different set of processes, each with their own set of steps.) Hmm, how easy will this be to correct?
For some context, it wasn’t all that long ago – say around 3.5 of Entity Framework – when I would basically have to start over with this kind of massive database change. I remember creating a WCF service where any major entity changes would involve creating a new model – and God forbid if the ID primary key field wasn’t called exactly that, “ID”, and in upper case! Now, with EF4.5, those dark days are gone.
- I go into SQL Server and change my relationships, blowing away the ProductTypeID field in the Step table, and setting up the link properly from ProductType to Process:
- Now I go back into my trusty IDE and open up the model. I right-click on the diagram and select “Update from Database” option. I don’t have to do anything special here – it knows to refresh any entities currently displaying on the diagram.
… And I get this awesome error message.
I’ve been down this rodeo before – this means I’ll have to manually go through and remove field references, both on the Controller side, the View side, and in the model codebehind. The agony! Or, since I put so little effort into these views and controllers anyway, maybe I can just – I don’t know – blow them away and repeat steps for both Step and Process. I’m not emotionally invested yet into any of these views, right?
- So, I go into the diagram and delete those two tables. (No, it doesn’t drop them from the underlying data layer!!) Now I right-click on the diagram and select Update from database, and add back my two errant tables:
It builds, and the forms look great!
Anyone in the .NET world is aware, or at least we should be, what a sea change Nhibernate and Ruby on Rails was when they first appeared – and what a challenge they were competitively in terms of speed-to-market. Entity Framework (and in its early forms Dynamic Data sites) may have been late on the gate – and we still have pockets of resistance from developers that perversely seem to enjoy writing all their database connectivity and middle layer logic by hand, line by line (these are probably the same ones that enjoy “hand crafting” html in Notepad!).
But there’s really no excuse for not using Entity Framework and the power of being able to quickly develop a frontend with both traditional webforms and model-view-controller (MVC) logic to show your bosses cannot be denied. Add to it responsive design and changeable themes with Bootstrap and I think its safe to say, Visual Studio has caught up with a vengeance.
- Powerful and extremely performant websites right now are running entirely on EF. Please, get to know both model-first, code-first, and database-first development – what I used above was database-first, but that’s only one option – and which works best for your project.
- MVC should be your default choice in writing an application, WebForms a distant second. Put simply, the advantage in code cleanliness, maintainability and testability far outweigh the few days it will take you to learn what the pattern has to offer.
Even though WebForms in ASP.NET 4.5 now have URL routing, we still have the potential of a bloated codebehind and an overreliance on an outdated and dangerous Viewstate model. MVC isn’t a fad and it isn’t a cure-all, but I think it’s well worth the investment of time it takes to learn.