I have to develop an application to store some flat files in the DB.. The Console application and the SQL Server will be on the same machine, which of these two options is the best?
Create WCF Data Services and use it from the console app
Use directly the Entity Framework entities from the console app
Generally, when it is better to use WCF Data Services or Entity Framework?
THANKS!
Those are two totally different technologies:
Entity Framework is an OR mapper to make your database access easier; you can compare this to e.g. NHibernate, Linq-to-SQL, Subsonic, Genome, or other OR mappers
WCF Data Services is a way to expose your data models to the outside world over HTTP/REST; compare this to legacy ASMX webservices, pure WCF services, other service technologies
You cannot compare the two - they're totally different beasts, and in many solutions, they will be working together - one cannot replace the other.
If you have a console app that needs to read data from a database, you can either use Entity Framework directly - in that case, your console app must have a direct connection to the database, and it's tied to the Entity Framework technology.
The option of exposing the data using a WCF Data Service adds another layer - your console app doesn't access the data directly, but it just calls a WCF Data Service. Now you basically have two parts: your console app as the client, and some kind of a service app that will provide the data. In that case, your client doesn't need to know anything about Entity Framework or anything like that - you could also easily add a second client, e.g. a web app. But the service app that provides the data will still need to be able to directly connect to the database using Entity Framework.
So in the end, you're not really replacing Entity Framework with WCF Data Services - you're just adding another layer of indirection, but in the end, to get at the data, you still need some kind of data access technology (like Entity Framework).
Related
Is there a clever way to structure my WCF service, such that I can implement a service once and have it return different data contracts for different callers? (i.e. mobile clients)
We have already developed a set of services which are consumed by a desktop application and are now building a mobile version of the application. The problem is that the data transfer objects (DTOs) returned are too big and contain unnecessary members for the mobile application. With it going over a mobile network we would like to cut these out to improve performance, however the implementation of the services will be identical.
Ideas we have so far:
Setting
EmitDefault to false and then not mapping all properties on the
DTO for mobile callers (we are using automapper so may be able to do something
with multiple mapping configurations)
Inherited DTO types for desktop that extend the basic mobile type using the KnownType attribute.
Just building a separate service entirely, but making sure all logic is in a shared business service layer (which it should be already)
Does anyone know if there is any guidance out there for this requirement?
Personally I would keep the implementations separate. As you point out, each set of clients - mobile and desktop - have different requirements. You can share the contracts for your service, just have different implementations / services. This will allow to specialise the services for each client, and makes it easier to extend, modify and test.
I have an existing set of Services and Repositories I use in an MVC application that leverage the Entity Framework 4.1 Code First.
I want to create a couple of WCF Services that use the existing architecture, but it seems to have a hard time serializing the object graphs.
I realize that there are some circular references to deal with, but I really don't want to litter the Domain Objects with WCF attributes, so should I just create View Models like my MVC app uses? And if so, should I create the View Models to be able to be used in both?
Any other ideas? - Thanks!!
I prefer keeping my domain model and the WCF data contract separate by defining Data Transfer Object classes as the data contact of the WCF server. They are tailored specifically to carry the right data across the wire. A good DTO design will keep the number of WCF service call roundtrips from the client down. It will also separate your internal domain model from the contract with the client.
I have just started evaluating whether or not I should be using OData influenced wcf data services or a standard WCF service application as the primary data source for Silverlight applications. I would like your thoughts on which is a better way under what situation/circumstance. What is lighter over the wire, easier to maintain, etc.
What I have gathered so far is:
There are no Wcf data service templates in VS2010 that I know of, and I will need to create a asp.net web project first and then add a wcf data service, so its going to affect how I structure my projects.
WCF Data services expose actual table names over the service. I don't know yet of a way I can alias them and I'm not sure its a good idea to let the world know my table structure
In a standard wcf service I will need to write linq queries against the EF or Domain service classes on the service side, while in a data service I can move that processing logic to the client.
At first glance examining the classes exposed by the wcf data services seem easier to read and understand than those exposed by the EF
Do add your thoughts on this..
Thanks for your time.
There are no Wcf data service
templates in VS2010 that I know of,
Not project template - just an item template (for use inside an ASP.NET web site or web app). WCF DataServices are very tightly coupled to HTTP, so they only make sense in a web site/app.
WCF Data services expose actual table
names over the service.
NO ! At least not necessarily. The whole point of EF is that you can decouple the actual physical structure of your database from the (conceptual) model that gets exposed. You can totally rename entities, you can map several entities onto a single table, split up an entity over several tables, you can leave out attributes - anything you like!
At first glance examining the classes
exposed by the wcf data services seem
easier to read and understand than
those exposed by the EF
I doubt it - because by default, WCF Data Services will use a Linq-to-SQL or EF model as their basis, really. You can make that as simple or as complicated as you like.
Using a "regular" WCF service allows you to use the netTcpBinding for much faster performance (thanks to binary message encoding vs. textual messages for other bindings), when using your Silverlight 4 app in a company-internal network (doesn't work for internet scenarios) - not something you can do with WCF DataServices.
The main difference in my opinion is the SOAP vs. REST difference:
SOAP (traditional WCF) is oriented towards methods - you think and design your system in terms of methods - things you can do (GetCustomer, SaveOrder etc.)
REST (the WCF DataServices approach) is all about resources, e.g. you have your resources and collections of resources (e.g. Customers) and you expose those out to the world, with standard HTTP verbs (GET, POST, PUT, DELETE) instead of separate specific methods that you define
So both approaches have their pros and cons. I guess the most important question is: what kind of app are you creating, and what kind of user audience are you targetting?
Update:
for intranet / internal apps, I would think the advantage of a netTcpBinding (binary encoding) would justify using a classic WCF service - also for data-intensive apps, I personally find a method-based approach (GetCustomer, SaveCustomer) to be easier to use and understand
for a public-facing app, using HTTP and being as interoperable as possible is probably your major concern, so in that scenario, I'd probably favor the WCF Data Service - easy to use, easy to understand URLs for the user
There a lot of different ways a Silverlight application can connect back to it’ server. Including
WCF - Windows Communication Foundation
REST (see also)
ADO.NET Data Services (or is this just REST?)
POX - Plain Old XML (E.g basic xml)
RIA services
For each of these please say what it’s for and when you would or wouldn’t use it. I am not looking for a great level of details just a set of “rules of thumb” for choosing between them.
(The problem is when designing your first Silverlight application knowing what to use when you don’t have time to learn all of them.)
If I was to replace Silverlight with WPF in this question what effect would it have on your answers? (I am assuming with WPF that due to firewalls and admin policies a direct connect to the database is not an option.)
My two (euro) cents:
WCF seems best suited when the service can be viewed as the business layer of the application, that is, when your service has "intelligent" operations like "CalculateDiscountForClient".
ADO.NET Data Services (indeed, just a REST implementation) seems appropriate when your application is basically data-centric and the service is simply a front-end for the database. That is, all your service methods are of type GetCustomers, CreateInvoice, etc.
RIA services is a very new technology that I haven't experimented with yet, but it seems to be useful to create applications in which the Silverlight part and the service are very tightly coupled: you define your service classes and methods in the service project, and they are automatically replicated to the Silverlight project in design time. Also, you can define both WCF-style "action" methods and ADO.NET Data Services-style "data" methods. Looks promising.
Use POX if there is a chance that you change the client part from Silverlight to any other technology (for example HTML+AJAX) in the future, since it is the most interoperable option.
About differences for WPF, the only I can think of, is that for data access, whenever possible I would use direct ADO.NET data connections (properly embedded in a data access layer, LINQ to SQL or the like) instead of ADO.NET Data Services, since it is way more flexible. I must say anyway that I have never developed anything in WPF.
We use RIA, and that's the only one of the options that I know, but I do know it, so here's some of my thoughts.
RIA isn't finished yet. It is being worked on. If you are planning to be finished soon, and you're worried about having to support something that has a potential to change quite a bit, then you might want to consider other options. If this is a new project, and you're going to be supporting it for a long time, RIA will probably get easier to use.
Having said that, I kind of think that there won't be many changes in the way the July Preview of RIA works and the way that a finished version will work. Also the level of support seems to suggest that this will become "The Way" to talk to a server in Silverlight.
Just cause it's worth mentioning, have some links:
http://blogs.msdn.com/brada/ Brad Abrams has an example that he is continually updating.
http://forums.silverlight.net/forums/53.aspx this is where you go to ask questions.
http://www.riaservicesblog.com/Blog/ Colin Blair knows his stuff, and he is very helpful.
I think I would not go POX ever again. If you write WCF so that the service itself is independent of the binding and binding is done in configuration files, then WCF is pretty much agnostic about transport and protocol. It can do SOAP, JSON, REST, or its own form of binary serialization. All of this is in the binding. Internally, WCF only specifies what gets exposed in terms of operation and data contracts (all defined by class, method, and property attributes). WCF gives you tremendous flexibility in this regard, with more to come in 2010.
From the Silverlight side, WCF requires that you write some plumbing code. The .NET frameowrk has the tools to build the proxy in your Silverlight project, but you must be prepared to handle all WCF responses asynchronously, and the proxy cannot catch exceptions thrown by the service.
.NET RIA Services hides all this. It uses WCF under the covers, but that is completely hidden. You don't have to write asynchronous code. You define validation once, mostly declaratively, and it works both server-side and client-side. Release 1 will be targeted for Silverlight, so you don't get the versatility to use the service elsewhere. That scope is supposed to be broadened in later releases.
I don't know enough about ADO.NET Data Services to compare. I suspect the answer would depend on whether you want to expose your data to more than just Silverlight usage.
.NET RIA Services looks like the direction I'd want to go (looking at these issues myself, with a large application in mind). The big issues for me will be implementing a very large collection of functionality in the service layer, and not being able to code directly to the data access layer (we have to be able to run on either SQL Server or Oracle).
Using WPF instead of Silverlight changes everything, depending on where your data resides. It's like the old question of Winforms vs. ASP.NET. With WPF, you're building a Windows client app, and you don't need to use any form of service-based data interface at all, unless your data access forces you into it. You'll still want to separate data and business from presentation code, using MVVM, MVC, or MVP. Other than that, you have the option to treat data access as a layer, rather than a wholy independent tier.
WCF is Microsoft's standard for service communication. I would strongly advise anyone to create a service layer using WCF Web APIs (uses WCF, but tailored specifically for REST), which is coming out this April 2012. WCF Web APIs is currently in preview mode.
Remember these rules of thumb:
- your UI will change faster than your service layer. RESTful services will be around in several years, Silverlight probably won't
- will your services ever be APIs? Well...WCF REST is the way to go
- will you mix JavaScript and Silverlight code? WCF REST will make your life easier
- will you have a mobile component (since Silverlight won't run on iOS or android)...REST is preferred.
Don't tailor to the technology, but the app as a whole.
If you want to create a Silverlight Application and you do not care about other clients, then I would choose RIA Services. It is quite painless to use and you do not need to worry how the connection from the client is made (i.e. no client side configuration necessary). RIA also generates classes for all your entities on the client and you can even share your own "server" code with the client if required (useful for enumerations or extension methods).
Remarks:
I never tried this, but if you really need you can access the RIA Service also with other clients, after all RIA Services are built on top of WCF services.
I do not quite understand Akash Kava's security concerns. You can (and have to) control security on the server-side as you would do with any other service.
I have a custom data entity (data object) that is exposed via a WCF webservice. The WCF service lives in a web application. I then have a Silverlight application with a service reference to that WCF service. When i add the service reference a proxy is generated, and that includes a version of the custom data entity.
How should i structure my code so that the data entity is declared in one place, and shared amongst the project containing the WCF service and any Silverlight applications that reference it? I want to eliminate the version of the data entity that is generated with the proxy.
There is a good example of how to do this here by Pete Brown. Using that approach you can use the same classes in both the Silverlight client and in the WCF service without having to use the generated objects.
Declare the data entities in the WCF service or a project that the service refereneces, then from the Silverlight project add the entities as links and make sure the "Reuse types in referenced assemblies" checkbox is selected from the Service Reference Settings dialog.
You can put the types in either the Silverlight or WCF side.
I have tried doing things this way and found that using DTOs instead and mapping them to the entities in the Silverlight side to be much cleaner and easier to work with although I did write a bunch of mapping code to get the DTOs into the entities and vice versa.
I´m not quite shure why anybody want to do that. You have to understand that the type you find in the proxy is a projection of the Type you have at Service server site. It´s defined in the *.g.cs files and gets generated new if you update the service reference.
In my opinion it´s the best way to have it declared in a single location, and project it. You need it in two places and it´s single defined.
I may be wrong anyway .....