I want to evaluate the feasibility of writing a WCF service for my DevExpress XAF/Entity Framework Winforms application to use.
Dev Express suport for this question indicates that this would be quite difficult, because XAF uses dynamically-generated queries to select and modify data.
Never the less, I am wondering how to go about it.
I have thought of simply connecting to the remote database without having a middle tier, but the answer here makes me think that this would be unsatisfactory.
There is no problem with creating a WCF service with XAF. In fact DevExpress have documented the steps. The dynamically created queries are passed to the middle-tier for security checks and execution and the results are returned.
But as it stands, the middle tier functionality is in beta and does not support EntityFramework, only XPO (and it does not look like it's made it into 15.1 which will be released soon has just been released).
Note can also access the XAF middle tier data via OData. Again, only XPO for the time being.
Related
My application currently accesses SQL Server the "traditional" way - via EntityConnection on top of SqlClient. I would like to add the option of accessing SQL Server via a new OData service. Any ideas on the best way to do this? Is it possible to reuse the existing model-first EntityObject-derived classes? Thanks!
The best way would be to follow this tutorial to create an OData service: http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-v4/create-an-odata-v4-endpoint.
Update adding more details given the comment:
Although the link should be enough for answering the question, I can also elaborate on the end-to-end scenario a little bit.
Now the premium experience of creating an OData V4 service out of an SQL Server DB is to use the ASP.NET Web API 2.2 for OData V4. With the help of the code-first aspect of entity framework you can create an OData V4 service that supports pagination, queries, and CRUD operations in a very reasonable time (about 10 minutes for every table in your database).
As soon as the service is created, various client libraries that supports consuming V4 services can be at your service. The premium experience on the .NET platform is the OData v4 Client Code Generator.
If your consumer is a non-developer, Power Query can help you import the data from the OData service. Their support for V4 services will come early next year according to this, but Excel and Power Pivot already natively support consuming V1-3 services. For creating a V1-3 service, the tutorial next to the one I gave at first would help.
I really like OData (WCF Data Services). In past projects I have coded up so many Web-Services just to allow different ways to read my data.
OData gives great flexibility for the clients to have the data as they need it.
However, in a discussion today, a co-worker pointed out that how we are doing OData is little more than giving the client application a connection to the database.
Here is how we are setting up our WCF Data Service (Note: this is the traditional way)
Create an Entity Framework (E)F Data Model of our database
Publish that model with WCF Data Services
Add Security to the OData feed
(This is where it is better than a direct connection to the SQL Server)
My co-worker (correctly) pointed out that all our clients will be coupled to the database now. (If a table or column is refactored then the clients will have to change too)
EF offers a bit of flexibility on how your data is presented and could be used to hide some minor database changes that don't affect the client apps. But I have found it to be quite limited. (See this post for an example) I have found that the POCO templates (while nice for allowing separation of the model and the entities) also does not offer very much flexibility.
So, the question: What do I tell my co-worker? How do I setup my WCF Data Services so they are using business oriented contracts (like they would be if every read operation used a standard WCF Soap based service)?
Just to be clear, let me ask this a different way. How can I decouple EF from WCF Data Services. I am fine to make up my own contracts and use AutoMapper to convert between them. But I would like to not go directly from EF to OData.
NOTE: I still want to use EF as my ORM. Rolling my own ORM is not really a solution...
If you use your custom classes instead of using classes generated directly by EF you will also change a provide for WCF Data Services. It means you will no more pass EF context as generic parameter to DataService base class. This will be OK if you have read only services but once you expect any data modifications from clients you will have a lot of work to do.
Data services based on EF context supports data modifications. All other data services use reflection provider which is read only by default until you implement IUpdatable on your custom "service context class".
Data services are technology for creating quickly services exposing your data. They are coupled with their context and it is responsibility of the context to provide abstraction. If you want to make quick and easy services you are dependent on features supported by EF mapping. You can make some abstractions in EDMX, you can make projections (DefiningQuery, QueryView) etc. but all these features have some limitations (for example projections are readonly unless you use stored procedures for modifications).
Data services are not the same as providing connection to database. There is one very big difference - connection to database will ensure only access and execution permissions but it will not ensure data security. WCF Data Services offer data security because you can create interceptors which will add filters to queries to retrieve only data the user is allowed to see or check if he is allowed to modify the data. That is the difference you can tell your colleague.
In case of abstraction - do you want a quick easy solution or not? You can inject abstraction layer between service and ORM but you need to implement mentioned method and you have to test it.
Most simple approach:
DO NOT PUBLISH YOUR TABLES ;)
Make a separate schema
Add views to this
Put those views to EF and publish them.
The views are decoupled from the tables and thus can be simplified and refactored separately.
Standard approach, also for reporting.
Apart from achieving more granular data authorisation (based of certain field values etc) OData also allows your data to be accessible via open standards like JSON/Xml over Http using OAuth. This is very useful for the web/mobile applications. Now you could create a web service to expose your data but that will warrant a change every time your client needs change in the data requirements (e.g. extra fields needed) whereas OData allows this via OData queries. In a big enterprise this is also useful for designing security at infrastructure level as it will only allow the text based (http) calls which can be inspected/verified for security threats via network firewalls'.
You have some other options for your OData client. Have a look at Simple.OData.Client, described in this article: http://www.codeproject.com/Articles/686240/reasons-to-consume-OData-feeds-using-Simple-ODa
And in case you are familiar with Simple.Data microORM, there is an OData adapter for it:
https://github.com/simplefx/Simple.OData/wiki
UPDATE. My recommendations go for client choice while your question is about setting up your server side. Then of course they are not what you are asking. I will leave however my answer so you aware of client alternatives.
Why do people call RIA services a black magic? What kind of black magic do they refer to ? Also, i have seen most people do not use RIA even though they are in Silverlight world. Why is it so? Even on stackoverflow, the % of people asking as well as answering to RIA services question is very very low. Why is it so?
WCF RIA Services provides the following benefits:
Makes a WCF RIA service that supports IQueryable and IEnumerable; WCF RIA Services creates client-side proxy which allows you to send only expression trees over the wire from the client in order to get back just the data you need. For example: you can call a method in your ria service called GetProducts() but also add a LINQ lambda such as GetProducts().Where( d => d.Quantity > 50 ) and only the expression is sent over the wire to the server. The server does the filtering and returns just the matches as strongly typed objects.
Dynamic generation of OData, REST/JSON, and SOAP endpoints with little more than a single line per endpoint in your web.Config.
Ability to automatically flow business rules created at the middle tier into the client tier
Allows you to efficiently flow validations from the middle tier to the user
Allows property, parameter, method, object, collection, and changeset level business rules through simple data annotation validator decoration
There are some deficiencies:
Still does not support WS-* (will in 5) for RPC
OData provider is not queryable
Well, I have not yet heard of people referring to WCF RIA Services as black magic.
I believe there is a small number of people using it (compared to the number of people writing stuff in Silverlight), because it is younger. People may have been developing their Silverlight applications for some time now (version 3.0 came out in July 2009) using classic WCF Services.
WCR RIA Services is still new (version 1.0 came out in May 2010, the final SP1 in December 2010) and we all know the rule, "Never change a running system", so if someone already has a working WCF webservice, why change it? In my case, we experimented with Silverlight and WCF some time ago and decided to wait. When RIA Services came out we thought that was great and started working on a Silverlight version of our main application. It is much easier using RIA Services in a new project than chaning your webservice access in an existing one.
In addition to that it should be noted that Silverlight is not limited to business applications with database access using a webservice. Therefore there may be quite a few Silverlight developers who do not need any kind of webservice.
Another reason might be the fact that for web applications requiring a database other technologies like ASP.NET, ASP.NET MVC, even PHP or JSP (and possibly others I may not even have heard of) have existed for quite a while. And although business applications ought to look nice, too, it usually is not the top requirement to have all kinds of fancy graphics and animations, etc.
Finally, why are so few questions regarding RIA Services asked on SO? Well, they do have their own forum which seems to be quite active. (I use it as a resource when looking for answers but don't post there.)
Regarding the "black magic" part of your question, I believe it is the ongoing shift to convention over configuration. Compared to vanilla WCF, you end up writing very little code to build the client-server relationship. Also, the WCF RIA tooling does a substantial amount of code generation to achieve this.
More on convention over configuration on specifically with WCF RIA and generally at Wikipedia.
We have a complex architecture with much logic in unmanaged code that needs database access.
Currently this is via ODBC drivers and MFC classes and we're considering the issues of migrating our abstraction layer to use ADO or ADO.Net. In the latter case we'd have to be pushing database logic back up into the .Net layer. I'm trying to decide if the pain of invoking the database via .Net callbacks is offset by the improvements in ADO.Net.
The Wikipedia comparison was interesting although I'm not sure I believe all the points in the comparison table (eg: does ADO.Net always use XML to pass data?).
A 2005 comparison shows ADO.Net performing dramatically faster.
Microsoft's guide to ADO.Net for ADO programmers suggests we will gain much from going to ADO.Net especially the way that data is available in native (.Net) types rather than solely through OLEAutomation's Variant.
eg: does ADO.Net always use XML to pass data?
No. Sounds like idiot information in wikipedia then.
2 choices. First, I would REALLY get rid of ODBC - and move at least to OleDb driver wise. If possible (tell me - I have a .NET app using an ODBC driver to call a JDBC ddriver to call a third party application server).
Now, you can go both ways - ADO on both sides, managed ADO.NET and expose from the NET layer - but this is really not a programmer decision, it is an architectural thing that should be seen in the major context.
I would possibly go for a .NET layer, possibly with at the same time an OData exposure layer, and try to consume that from the unmanaged layer.
I’m just working on this interesting thing with ADO.net entities and need your opinion. Often a solution would be created to provide a service (WCF or web service) to allow access to the DB via the entity framework, but I working on an application that runs internally and has domain access pretty much all the time. The question is if it’s good practice to create a data service for the application to interface from or could I go from the WPF application directly to the entity framework. What’s the best practice in this case and what are some of the pros’ and cons’ to the two different approach.
By using entity framework directly, do you mean that the WPF application would connect to the database, or that it would still use services but re-use the entities?
If it's the first approach, I tend to be against this because it means multiple clients connecting to the database, which a) is an additional security concern, b) could make it more expensive from a licensing perspective, and c) means you don't get the benefits of connection pooling. Databases are the most expensive things to scale so I'd try to design the solution to use services and reduce the pressure on the database. But there are times when it's appropriate. One thing I've noticed is that applications which do start out connecting directly tend to get refactored to go via a service later; it seldom happens the other way around. But it might also be a case of YAGNI.
If it's the second approach, I think that's fine. It's common for people looking at WCF to think "service oriented" - that is, there should be a strict contract between services and things shouldn't be shared. But a "multi-tier" application, which is only designed to have one client, is also a perfectly valid architecture and doesn't need to be so decoupled. In that case, reusing the entities on both sides of the service boundary should be fine. However, I'm not sure how easy this is to do with EF specifically, since I haven't used it except in experiments.
It really depends on the level of complexity and the required level of coupling/modularity. I think a good compromise would be to create a EF model in it's own library or the like with a simple level of abstraction. In that scenario if you chose to change the model to use an exposed service instead of direct access it shouldn't be a big deal to refactor existing code and the new service could utilize the existing library.