Coffeehouse Thread

11 posts

Single Page Application minus EF

Back to Forum: Coffeehouse
  • User profile image
    itsnotabug

    The new SPA stuff in MVC 4 looks great (it's actually very close to a pattern that I've been naturally moving towards in my work without even knowing it). My problem is that all the samples and talks that I've seen are using Entity Framework.

    Are there any good SPA examples that don't use EF? I'm in love lately with micro-ORMs like PetaPoco and Dapper. Didn't see anything on Codeplex.

    I assume that I'd have to use DataController and ApiController to roll my own version of something like DbController, but I'm just not sure how all the pieces should be fitting together.

  • User profile image
    JohnAskew

    I haven't looked at the code, but your assumption is correct.

    Here's what they say regarding this: DbController is a DataController that implements the above for Entity Framework Code First style of data access.

  • User profile image
    cbae

    , itsnotabug wrote

    The new SPA stuff in MVC 4 looks great (it's actually very close to a pattern that I've been naturally moving towards in my work without even knowing it). My problem is that all the samples and talks that I've seen are using Entity Framework.

    Are there any good SPA examples that don't use EF? I'm in love lately with micro-ORMs like PetaPoco and Dapper. Didn't see anything on Codeplex.

    I assume that I'd have to use DataController and ApiController to roll my own version of something like DbController, but I'm just not sure how all the pieces should be fitting together.

    EF is required because the SPA project template does a lot of scaffolding of JavaScript as well as ASP.NET Web API code that is entity-specific, and the EF 4.x DbContext allows those entities to be discoverable. You can probably write your own Web API code and JavaScript plumbing that calls the appropriate Upshot and Knockout methods, but it's going to be pretty tedious depending on the complexity of your entity model.

    However, the entire ASP.NET web stack is open source so maybe you can fork the project and create some tooling to work with those particular ORMs.

  • User profile image
    itsnotabug

    @cbae: Oh man, that's not what I wanted to hear.

    I kinda understand that it's the 2-way binding part that would be tricky, but I figured there would be something like IDiscoverable/IBindable interfaces I could implement in my PetaPocoDbContext class that would play nice with Upshot.js as long as I handled the CRUD operations in my own data access code. From what I've seen it just looks like you need to throw some json into the view and upshot.js does everything on the client (I have admittedly not looked into the WebApi source).

    I guess there's a lot more going on Sad

    Anyway, thanks for the response. This would indeed be a great OSS codeplex project because there are a ton of Luddites out there like me who don't want or need the heft of EF (no matter how "good" it is) for some projects.

  • User profile image
    cbae

    , itsnotabug wrote

    @cbae: Oh man, that's not what I wanted to hear.

    I kinda understand that it's the 2-way binding part that would be tricky, but I figured there would be something like IDiscoverable/IBindable interfaces I could implement in my PetaPocoDbContext class that would play nice with Upshot.js as long as I handled the CRUD operations in my own data access code. From what I've seen it just looks like you need to throw some json into the view and upshot.js does everything on the client (I have admittedly not looked into the WebApi source).

    I guess there's a lot more going on Sad

    Anyway, thanks for the response. This would indeed be a great OSS codeplex project because there are a ton of Luddites out there like me who don't want or need the heft of EF (no matter how "good" it is) for some projects.

    If the entities of the ORM that you're using are simply POCO classes, you could create DbContext wrapper around those types in an separate assembly and reference that DbContext in the SPA project in order to get the scaffolding built. Then in the scaffolded Web API code, you'd swap out the references to the DbContext with whatever "context" type the ORM uses and remove the reference to the separate assembly containing the DbContext.

    The JavaScript code would remain untouched since it's only interested in the schema of the entities themselves.

     

  • User profile image
    itsnotabug

    It's looking more and more like I should just be using knockout.js + plain old jQuery for templating and CRUD in the ViewModel. I just need to expose the server side parts through WebApi, but I need to think about strategies for not allowing a user to fiddle with the DOM and post updates, inserts or deletes against IDs that they aren't privy to. WebForms had this kind of safety feature built in. I already have a forms authentication based shell of a project that handles users and roles. I guess I could do a granular security check against the current thread's user before any CRUD operation down to the ViewModel's ID level but that seems expensive. Maybe I can do my own poor man's ViewState? 

  • User profile image
    vesuvius

    , itsnotabug wrote

      My problem is that all the samples and talks that I've seen are using Entity Framework.

    If you had used EF you would have finished your task by now, instead of still head scratching two days later

  • User profile image
    JohnAskew

    @vesuvius: ...but he's in love...

  • User profile image
    cbae

    , itsnotabug wrote

    It's looking more and more like I should just be using knockout.js + plain old jQuery for templating and CRUD in the ViewModel. I just need to expose the server side parts through WebApi, but I need to think about strategies for not allowing a user to fiddle with the DOM and post updates, inserts or deletes against IDs that they aren't privy to. WebForms had this kind of safety feature built in. I already have a forms authentication based shell of a project that handles users and roles. I guess I could do a granular security check against the current thread's user before any CRUD operation down to the ViewModel's ID level but that seems expensive. Maybe I can do my own poor man's ViewState? 

    How is this easier than just creating a dummy wrapper DbContext that you would only use in design-time?

    And may I suggest that you look into EF 5.0. They made some huge performance improvements, and EF code first data migrations makes managing and deploying schema changes a snap.

  • User profile image
    itsnotabug

    @JohnAskew: LOL... my problem with EF is that it doesn't show me what's going on. I like micro-orms because i can step through and actually understand what I'm seeing. Too much abstraction for my tastes and i my option, pure SQL is the best way to query data. Some of my queries may very well be impossible with EF.

     

  • User profile image
    cbae

    , itsnotabug wrote

    Some of my queries may very well be impossible with EF.

    They accounted for queries that are too complex for LINQ by providing ObjectContext.ExecuteStoreCommand() and ObjectContext.ExecuteStoreQuery().

    And why do you even care about that EF can or can't do? Just use it for design mode. Keep it in a separate assembly. EF won't see the light of day in your production code.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.