Is it possible to use the parameters incoming from the webservice ( named 'Query' in my case ), in the SQL in the reader module.
I think it's possible, but I cannot find anywhere how to template these properties in the SQL query so that it becomes dynamic.
Currently, you'd have to implement the logic for inserting the query key in the client application that calls the web service. Support for parameterized SQL queries is in our feature backlog.
Yes you can. Here is the blog demonstrating "how-to" for web service parameters - http://blogs.technet.com/b/machinelearning/archive/2014/11/25/azureml-web-service-parameters.aspx
Related
if I implement the following api toystore.com/api/toys?$select=prodId&$filter=startswith(CompanyId,'lego') in ASP.NET, MVC, using odata3 and EF. Does that query get evaluated on my database (which is indexed and good at filtering) or do I retrieve all 100k rows and then filter them on my IIS webserver in memory? If it's the latter is there a way to make this more performant. thanks
edit - clarifying...
"can" asp.net odata queries ever filter on the database or are they always evaluated on the IIS?
related: Enable lazy loading on OData URL Query
If you return with IQueryable, where condition will be added in sql query. Thus, it will not pull all the data from the database. If you return an IEnumerable instead of IQueryable, it will pull all the data and filter it in iis.
I hope I have helped.
I'd like to include an embedded graphql processor in my .net app.
I want to execute GraphQL functions via a method and I don't need the server or an endpoint.
Basically an internal GraphQL processor. I'll define the resolvers and the schema and then run queries via a method call. Is this possible?
You may take a look NReco.GraphQL (which is based on GraphQL.Net but has an additional features, like aggregation, filter, ect.). You can compose in code schema, query (or query object) and call it just in-code.
I have problems deciding on how the OrmLiteConnectionFactory should be passed to the different classes. Should it be done by injecting the container into the constructors? It is a message based design if that matters.
Basically you'd just want to pass a "reference" to what connection you'd want your Service to be executed with.
ServiceStack's Multitenancy docs shows different approaches of specifying the DB connection to use per Request DTO message, including using a custom filter, or utilizing the built-in [ConnectionInfo] or [NamedConnection] attributes.
Or if you prefer you can resolve which DB connection you want to use with your Services logic by resolving it from a IDbConnectionFactory dependency.
I have a requirement where third party software running on a desktop will write to a local database and I need to send some of that information to a remote web service. I don't have any control over the thirdparty software that is doing the insert but I can read the database.
My approach is to have a windows service check the local table every second for an insert, if there is an insert send the webservice request. I don't like checking every second but this whole process needs to happen in a short amount of time after the insert. Is there a better way to go about this? Some kind of listener? I don't think I can use triggers.
This will be .NET and SQL Server if that matters.
Try using the SQLDependency class. Implement the onChange method of the class to handle your processing. The following article describes the process of configuring your environment and has some sample code for this.
http://www.codeproject.com/Articles/144344/Query-Notification-using-SqlDependency-and-SqlCach
I am already using the standard WebAPI and returning JSON objects to my client. Now I saw an application that returned OData.
Can someone explain if there is any reason for me to use OData if I do not want to query my data from anything other than my own client running in the browser. Are there advantages that I could get through using OData ?
If you are only using your data in your own browser application, there is only few advantages to use OData in your situation:
OData is able to provide metadata about your service interface that can be used to generate client code to access the service. So if you have lots of client classes that you need to create, this could speed up your process. On the other hand, if you can share your classes between the server and an ASP.NET based client or if you only have a few classes, this might not be relevant in your situation.
Another - bigger - advantage in your situation is the support for generic queries against the service data. OData supports IQueryable so that you can decide on the client side on how to filter the data that the service provides. So you do not have to implement various actions or use query parameters to provide filtered data. This also means that if you need a new filter for your client, it is very likely that you do not have to change the server and can just put up the query on the client side. Possible filters include $filter expressions to filter the data, but also operations like $skip and $top that are useful when paging data. For details on OData and queries, see this link.
For a complete overview about OData and Web API see this link.
Here are few advantages of OData.
OData is a open protocol started by Microsoft is based on Rest Services so we can get data base on URL.
It suppport various protocol like http,atom,pub and also support JSON format.
No need to create proxy classes which we used to do it in web service.
You will able to write your own custom methods.
It is very light weight so the interaction between client and server will be fast compared to web service and other technologies.
Very simple to use.
Here are few reference links.
http://sandippatilprogrammer.wordpress.com/2013/12/03/what-is-odata-advantages-and-disadvantages/
http://geekswithblogs.net/venknar/archive/2010/07/08/introduction-odata.aspx
http://www.zdnet.com/blog/microsoft/why-microsofts-open-data-protocol-matters/12700
I agree with the answers already posted, but as an additional insight...
You mentioned that:
... if I do not want to query my data from anything other than my own
client running in the browser...
You may not wish to run it normally through anything but your own cilent, but using oData you could use other querying tools for debugging. For example LinqPad allows you to use oData endpoints (such as that provided by stackoverflow).
It's probably not a good enough reason to implement oData if you don't have another reason to do so, but it's an added bonus.