I have started working on an application which is structured as follows:
UI - ASP.Net MVC web application
Service Layer - WCF
Entities - a simple class library (exposed by WCF layer)
Data Layer - for database interactions.
Till now, I was defining my models in Models folder of my web application, but now as we have decided to expose them by WCF service (as this application will be consumed by other applications as well), I need some help here.
I tried putting all my model definitions in Entity layer which is exposed by WCF service decorating them with data annotations as well as DataContract attributes. Now, I am able to reference these entities to bind them with my views. But, data annotation validations are not working for me.
Can anybody please help me for a workaround for this ? I have been searching through web for solution but almost all tell me to put a reference of entity layer in web application which will be tight coupling that we do not want. and the other option is to redefine all entities with data annotations in models folder of my web application,which will be duplicate kind of coding.
Is there any better approach for this? Any help appreciated.
Update:
To consume WCF entities, I have put a service reference in my web application. Now, just to check I modified that Reference.cs file by decorating my data Member explicitly with [Required] attribute and it is working fine. but, I understand these changes will go away whenever service code is generated.
Is there any way I can bring that Data annotation attribute here? Kindly help.
As for me It's bad idea, DTO for transfer, Model for MVC.
Look like similar problem
Why You Shouldn’t Expose Your Entities Through Your Services
DTO’s Should Transfer Data, Not Entities
I wrote a couple of simple web methods (as a part of WCF service) that use a couple of (more complex) classes as input/returned parameters. Each web method attributed by [OperationContract], each data class attributed by [DataContract], each data field in the classes attributed by [DataMethod].
On the client side I can call these web methods by adding Service Reference.
All things are fine, but when I create an instance of some of the data classes above on client side, their constructors don't run.
Because it's a little complicate to initialize each instance, every time, I thought there is some way to initialize instances on client side by their own constructors.
Thanks in advance!
Ilan.
Methods exposed on data contracts (including constructors) in your service are only for service applications. Adding service reference will recreated only data structure of your data contract classes because service description is not able to describe logic and logic cannot be serialized.
All classes created with service reference are partial. You can create your own partial class and add your own custom constructors or you can share the assembly with data contracts between your service and client (but it will share all logic added to your data contract classes which is most often what you don't want). Sharing assembly will tightly couple your client and service.
I have an class library called ServiceLayer which acts as a repository for a ASP.NET MVC application This service layer has a references to a WCF Service called ProfileService which contains Profile methods to perform CRUD operations on a database etc.
I now need to allow mobile devices to communicate with my application so I have created another WCF Service called ProfileService. This service has a reference to the ServiceLayer class library and makes calls to it to undertake Profile operations.
Now this is quite confusing as I now have 2 ProfileServices. The first communicating with my database etc and exposing itself to my service layer. The second communicating with my service layer and exposing itself to mobile devices.
What is the best way to name your services in a SOA environment to avoid confusion of which type is which? especially when mapping between types.
I may also want to create another service which acts as an API to users of the system. What would I name this service ProfileAPI?? I know each ProfileService is in its own namespace but this doesnt help with readability when creating AutoMapperSettings or performing manual mapping.
So if anybody out there knows of a good way to name services in this environment it would be much appreciated.
You are looking for a Service Facade
You would end up with a Facade, which is just a specialized interface into your real service. You would define the different services as needed (mobile, users, database)
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.
In Understanding WCF Services in Silverlight 2, the author, David Betz, explains how to call a web service without adding a service reference in the client application. I have a couple of weeks experience with WCF, so the article was over my head. In particular, although the author gave a lot of code snippets, but does not say what goes where. In the article, he provides two different code snippets for the web.config file, but does not clarify what's going on.
Looking at the source code there are four projects and two web.config files.
So far, I have been using the standard Silverlight project configuration of one project for the web service and one for the Silverlight client.
Firstly, does the procedure described in the article work with the standard two project configuration? I would think it would.
Secondly, does anyone know of a simpler example? I am very interested in this, but would like to either see source code in the default two project setup which is generated when a new Silverlight project is made, or find a step by step description of how to do this (eg, add a class called xxx.cs and add this code..., open web.config and add these lines...)
Many thanks
Mike Thomas
First, a little philosophy...
If you are a consumer of a WCF service that you did not write, adding a service reference to your client is really the only mechanism you have to enable interaction with that WCF service. Otherwise, you have no way of knowing what the service contract looks like, much less its data and message contracts.
However, if you are in control of both the client and the WCF service itself, adding a service reference to the client is a nice convenience, but I've recently been convinced not to use it. For one, it becomes a nuisance after the first few times you change your contract to remember to update your service reference. And in my case, I have several different C# projects that are consuming the WCF service, so I have to remember to update each one of them. Second, creating a service reference duplicates the contract definitions that are already defined in your WCF service. It is important to understand the implications of this.
Let's say your WCF defines the following type.
[DataContract]
public class Person
{
[DataMember] public string FirstName {get; set;}
[DataMember] public string LastName {get; set;}
}
When you add a service reference to your client, the metadata associated with this class is retrieved through the metadata exchange (MEX) endpoint, and an exact replica of this class is created on the client side that your client "compiles" against. So your WCF service has a definition of the Person class, and so does your client, but they are two different, distinct class definitions.
Given this, it would make more sense to abstract the Person class into a separate assembly that is then shared between the WCF service and the client. The added benefit is that when you change the contract definitions within this shared assembly, you no longer have to update the service reference within the client because it is already referencing the shared assembly. Does that make sense?
Now to your question. Personally, I've only used WCF within C# projects, not Silverlight. However, I do not think things are radically different. Given that, I would suggest that you watch the Extreme WCF video at dnrTV. It gives a step-by-step guide for how to bypass the service reference feature.
Hope this helps.
Let me try - I'm not an expert at Silverlight development, so bear with me if I say something that doesn't apply to Silverlight :-)
As Matt Davis mentioned, the "usual" use case is this: you add a service reference to a given service URL. In doing so, Visual Studio (or the command-line tool svcutil.exe) will interrogate the service and grab its metadata - information that describes the service, all the available methods to call, what parameter they expect etc. From this, it will generate a class for you (usually called the "client" or "client proxy"), which you as a client (=service consumer) will use to call the service. You can have this client proxy class generated inside your "normal" Silverlight client project, or you could possibly create your own "service adapter" class library, esp. if you will be sharing that client proxy code amongst several Silverlight projects. How things are structured on the server side of things is totally irrelevant at this point.
As Matt D. also mentioned, if you do it this way, you're getting copies of the service, its methods, and its data, in your client - those are identical in structure to what the server has - but they're not the same type - you on the client side have one type, the server has another (the fields and properties are identical though).
This is important to remember since the whole basic idea of WCF is message-passing - all that connects the client (you) and the server (the other end) are the messages and their structure - what method to call and what values to pass into that method. There's no other link - there's no way a server can "connect" to the client code and check something or whatever. All that gets exchanged is serialized messages (in text or binary form).
If you do control both ends, you can simplify things a bit - you can physically share the service contract (the definition what the service looks like and what methods it has to call into) and the data contract (the description of what data is being passed back and forth) on both the server side as well as the client side. In this case, you won't be adding a service reference, you won't be duplicating the service and data definitions, so things are a bit easier (but it only works if you're in control of both ends).
In this case, best practice would be to package up all that describes the service (the service interface with its methods and the data contracts) into a separate assembly (class library) on the server, which you can then copy to the client side, and reference directly from there (like any old assembly you might have). So in this case, you would typically have at least three projects in your solution:
your actual Silverlight client project
the website or web app hosting your Silverlight control for testing
the service interface assembly, which contains the service and data contracts
So there you have it - I hope I covered all the basics of what's going on, and why you would want to do one or the other thing. If you need additional info, don't hesitate to comment on this posting and let us know!
Marc