Quick post for the day. I was trying to configure a data source in a listview – converting over to EntityFramework from a SQL data source – and I got this funky message:
Hmmm. Why is this? Well, I had to open up my data models project, and change the ProviderManifestToken=”2012″ attribute to “=2008”.
And voila. Changing that one key – and this is a known bug with EntityFramework 6 that the team has on their list to fix – got me where I needed to go. I had my lot tracking admin screen up and going in about 5 minutes.
Webforms Versus MVC – Honestly, Who Cares?
P.s. – Webforms, rightly, have a bad name – because of bloated codebehind. But what happens when you drag on a listview, and click on the little arrow in the Design pane – and point to an EF data source with a PK? Suddenly, you have a fully functioning page – with NO codebehind – and all your upd/ins/del statements are coming straight from EF. That seems pretty clean to me.
To me – and to many others – ASP.NET Webforms and MVC are equivalent forms. IF your webform has no bloated codebehind, and is running from either a EF-generated model or, better, knockoutJS data binding – don’t you have a clean and easy to maintain architecture?
Webforms are bad if you have bloated codebehind. They’re good and equivalent to MVC without that code smell. MVVM – well, that is a superior pattern to both – but that’s for a future post.
Entity Framework is the default way that Microsoft wants us to be noodling around with data. And it’s easy to see why – this is MSFT’s answer to the challenge posed by Ruby, well over ten years ago. EF gets better with every version.
From the Getting Started documentation, it should just be a simple matter of
- Add a new diagram – and make sure for delete (for example) all changes are set to cascade.
- Add a new web form + master page.
- Add an Entity Data Source. In design view, configure it to point to your Entities data source you created in step #1.
- Add a new GridView. Select your entity data source. Select Enable Paging…. down to Enable Delete. Delete the ID fields.
- Set the Dates template, etc on any custom fields.
- Set up the ContextTypeName attribute to enable lazy loading.
However, I’m getting a “The provider did not return a ProviderManifest instance” error message. This usually indicates an issue with the connection string. I’ve tried switching to Integrated Security, changing the username/pwd – no dice. I honestly think this is a bug with EF6, since I’m using the most recent version of Entity Framework and I can’t recall seeing this issue in EF5.
Since the forms use sprocs by and large, and we are using webforms, I’m OK with – for now – going old-school and using sprocs not EF for my data connections. For our new app though I am going to revisit this and use either Linq-to-SQL or preferably that nifty BackboneJS/KnockoutJS + MVC stack and a webapi data layer.