locked
SignalR with OData RRS feed

  • Question

  • User1122355199 posted

    Hello everyone and thanks for your help in advance.  I have developed a few SignalR applications in the past using SQL Notifications for the push.  I've started a new project that allows, but does not require, the user to input 5 separate search parameters to filter a database search that will populate a table.  It was suggested in another forum that I implement an OData endpoint using the Entity Framework, but I have never worked with any of these technologies and don't understand how they can be implemented with SignalR, especially relating to SQL Notifications.  Any insight on these topics would be greatly appreciated.

    Friday, July 8, 2016 2:10 PM

Answers

  • User765422875 posted

    I believe you were given the suggestion to use OData with Entity Framework to facilitate the search requirement you are trying to implement. The use of OData with Entity Framework has nothing to do with how you would use SignalR.

    If understand you correctly, you want to notify any clients that the table you mentioned was populated? This is irrespective of performing the initial search with OData and Entity Framework.

    Here is a link to some OData with Web API tutorials and there plenty more examples online.

    https://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api

    EDIT

    Entity Framework Tutorial

    The following post will walk you through wiring SignalR with Entity Framework.

    ASP.NET MVC 5 SignalR, SqlDependency and EntityFramework 6

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, July 8, 2016 3:56 PM
  • User765422875 posted

    The answer to your performance question is - "it depends". Sounds generic, but it's true.

    If you are doing batch operations, ETL, working with legacy code that already uses stored procedures, and if you need to use a very complex query - then I'd say using stored procedures is fine.

    But for CRUD and queries against normalized databases - there shouldn't be performance concerns. The EF data context uses deferred execution for selects, and it batches record updates and deletes in a single database round-trip on Submit().  Entity Framework offers additional performance enhancements like caching, futures and batch operations (select, update and delete). These can have a dramatic impact on application speed.

    LINQ to Entities queries are not composed by using string manipulation or concatenation, and they are not susceptible to traditional SQL injection attacks.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, July 9, 2016 3:00 PM

All replies

  • User765422875 posted

    I believe you were given the suggestion to use OData with Entity Framework to facilitate the search requirement you are trying to implement. The use of OData with Entity Framework has nothing to do with how you would use SignalR.

    If understand you correctly, you want to notify any clients that the table you mentioned was populated? This is irrespective of performing the initial search with OData and Entity Framework.

    Here is a link to some OData with Web API tutorials and there plenty more examples online.

    https://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api

    EDIT

    Entity Framework Tutorial

    The following post will walk you through wiring SignalR with Entity Framework.

    ASP.NET MVC 5 SignalR, SqlDependency and EntityFramework 6

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, July 8, 2016 3:56 PM
  • User1122355199 posted

    First of all, thanks for the response.  You are correct in the suggestions I received, but I really don't know how to implement all the pieces.  Here is where I am struggling.  Typically, any type of SQL notification example that I have seen for SignalR incorporates into the hub the actual database calls that return the data after the update.  This hub is typically called on the initial page load under the $.connection.hub.start() that populates the table on the initial page load.  So if I understand correctly, the Entity Framework, the Entity Framework (I have never worked with it before) removes the ADO portion of the database call.  Since most of the examples I have seen on SignalR show the SQL notification in the hub, I have no idea how the database notification change would be sent.  I can't imagine you would need to build a separate notification class since that would nullify the benefits of the Entity Framework.  What am I not understanding?

    Thanks again for the help.

    Friday, July 8, 2016 5:59 PM
  • User765422875 posted

    Entity Framework is an ORM (object relational mapper). It handles all the low level plumbing that you would have to write if you were using straight ADO.NET. Importantly, it allows you to work with relational data as domain-specific objects as well as perform complex mappings.

    It does not technically remove the ADO.NET portion, it just abstracts it. It's all under the hood.

    Please see my updated answer with how you wire up Entity Framework with SignalR and SqlDependency.

    Friday, July 8, 2016 6:34 PM
  • User1122355199 posted

    Thanks for the response and the new information.  Not trying to be difficult, but it looks like you swap a lot of code to use Entity Framework, only to have to create a lot of code to get SignalR to work with it.  Is it really worth it and what do you gain.  While I understand the general concept of domain-specific objects, I'm not fully grasping what the benefit is in this individual case.

    Thanks again for the help.

    Friday, July 8, 2016 9:18 PM
  • User765422875 posted

    No worries, this what the "community" is all about.

    You have to use the data access technology / framework that best suits your needs. Personally, I use Entity Framework or Dapper when I'm building an application with a SQL Server backend. If it's a very large application with complex mapping requirements - then I normally opt for Entity Framework. Otherwise, I stick with Dapper. If you do not know what Dapper is - it's a micro ORM developed by the people at stackexchange. Its an extension off the IDbConnection interface. It's lightweight, and has excellent performance.

    I use straight ADO.NET if I am building a service or some utility that doesn't require any sort of mappings.

    I've used SignalR on several projects including a few that used Entity Framework and it worked fine.

    Perhaps in your individual case, Entity Framework may not add any value.

    Friday, July 8, 2016 11:52 PM
  • User1122355199 posted

    Again, thanks for the response and I appreciate your patience.  The problem is I am too ignorant to know what is best for my particular project.  By mappings, if you mean multiple types of CRUD calls, my particular project is full of them.  The particular page is part of a physician practice management system with multiple types of CRUD operations, so I suspect it is a good candidate for EF and OData.  Part of the project is the refactoring of 12 year old code embedded in code-behind pages and class libraries, so I would l like to move the entire project into something more extensible and consistent with the new mobile architecture.   So basically, the idea behind modern architecture is to move class libraries or their equivalent to some type of web api so they can be consumed both locally as well as on the web.  Entity Foundation replaces the need for repetitive ADO tasks that would require numerous classes that can now be rolled up into one.  So the reason to incur the overhead is to make the data previously called by class libraries accessible to more applications.    Am I basically getting the point?

    Saturday, July 9, 2016 1:06 AM
  • User765422875 posted

    Yeah if you have lots of CRUD operations going on and you are repeatedly doing the same thing over and over again with straight ADO.NET - then an ORM would be helpful.

    Web API is a framework that allows you to build RESTful HTTP services. So yes, you could move the code you have behind a Web API interface which would allow you to expose your data to a broader audience.

    Coupling that with Entity Framework and OData - it would give you a uniform way to query and manipulate your data through CRUD operations.

    I think you are definitely getting the point.

    Saturday, July 9, 2016 1:54 PM
  • User1122355199 posted

    Thanks so much.  I'm going to try and put one together so I'll probably be posting again on this topic.  Two other questions.  Does EF take a performance hit over using stored procedures?  And is it more prone to SQL injection attacks?

    Saturday, July 9, 2016 2:16 PM
  • User765422875 posted

    The answer to your performance question is - "it depends". Sounds generic, but it's true.

    If you are doing batch operations, ETL, working with legacy code that already uses stored procedures, and if you need to use a very complex query - then I'd say using stored procedures is fine.

    But for CRUD and queries against normalized databases - there shouldn't be performance concerns. The EF data context uses deferred execution for selects, and it batches record updates and deletes in a single database round-trip on Submit().  Entity Framework offers additional performance enhancements like caching, futures and batch operations (select, update and delete). These can have a dramatic impact on application speed.

    LINQ to Entities queries are not composed by using string manipulation or concatenation, and they are not susceptible to traditional SQL injection attacks.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, July 9, 2016 3:00 PM
  • User1122355199 posted

    Thanks so much.  I need to dive in!

    Monday, July 11, 2016 12:42 PM