Maintain a Dictionary with WCF RESTful Service - c#

I need to write a RESTful WCF service that maintains a dictionary (or any other suitable data structure) with userId:userData as key:value pairs.
For that I first need to implement an interface for getting and setting userData (the specific configuration is enclosed):
GetConfiguration() : returns default config when user hasn’t set a config yet
GetConfiguration(string id)
SetConfiguration(string id, Configuration configurationSchema)
Then I'll need to write a service that implements this interface.
As a newbie in WCF I'm not sure how to do it. I tried to look for relevant references but didn't found any.
Appreciate any help/relevant references, Thanks !
The userData object:
public class ConfigurationSchema
{
public string MobileNumber { get; set; }
public List<string> Habits { get; set; }
public ConfigurationSchema(string mobileNumber, List<string> habits)
{
this.MobileNumber = mobileNumber;
this.Habits = habits;
}
}

may be below video will help you to create a WCF service. Once create simple WCF service after that add your code.
https://www.youtube.com/watch?v=GzN1vHWlJjA

If you did not find references to help you, I'd suggest you learn to google before you tackle programming problems. It's worth it. For your problem:
Open Visual Studio
Chose WCF project
Replace example complex data structure by your own class
Rename methods
Rename interface
Press F5

Related

Can't access public class from web service

I have a very weird scenario which I can't seem to figure out what's going on. I have a web service which is written in C# and the target framework is 3.5. I have many Classes and Methods but for simplicity I will make use of only two classes in the question.
public class PathNames
{
private string _pathA = "Some Path";
private string _pathB = "Another Path";
public string BaseDirectoryPath
{
get
{
return Path.Combine(_pathA, _pathB);
}
}
}
The second class is as follows:
public class UserInformation
{
public string UserName { get; set; }
...//more properties
}
Both of the above classes are in the same namespace.
The web service is referenced in a WebForm Application with the target framework being 4.0. Everything seems to be working fine and I can see the UserInformation class when I view it in Object Browser. However the PathNames class does not seem to be visible in the Object Broswer.
Both of the source files in question are set to Compile in the File Properties windows. I have 5 classes similar to that of UserInformation and same settings in the File Properties window where they are just simple POCO and only have public auto propteries. These all seem to be coming through and I can access them and see them in the Object Browser. For some strange reason I cannot PathNames class to come through. I have tried to add some new dummy classes and have the same issue as PathNames class. Can someone tell me what I am doing wrong please.
The web service old ASMX
Web service client is being created through VS add service reference
Using VS 2017 pro - version 15.6.7.
After publish if I de-compile the dll then the PathNames class is there. So it's clearly in the dll.
I have look at this but still no luck.
Using Data Contracts in web service
Service can't expose private/read-only properties. DataMember attribute is used for marking public members or properties (with public getter and setter) of class marked with DataContract attribute. DataContract can be used as parameter or return value of operation.
Windows Communication Foundation (WCF) uses a serialization engine called the Data Contract Serializer by default to serialize and deserialize data (convert it to and from XML), and XML serialization (by default) doesn't serialize read=only properties.
For More Information you can read the MS Docs for Data Contracts :- https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/using-data-contracts
To understand the various Limitation of Data Contracts please refer : -https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/types-supported-by-the-data-contract-serializer
Solution :
Anyway. What are you trying to do? Exposing properties means that you expect some stateful behavior. If you going to use this property in operation contract, which is seems to be, then you you must define the properties with public getter and setter so it can be serialized.
As the #Nikosi stated in previous answer, you have to define public setter for your BaseDirectoryPath property.
The only difference based on the example provided that one property is readonly while the other can be modified.
In order to make the class serializable consider rafactoring the property
public class PathNames {
private string _pathA = "Some Path";
private string _pathB = "Another Path";
public PathNames() {
BaseDirectoryPath = Path.Combine(_pathA, _pathB);
}
public string BaseDirectoryPath { get; set; }
}
You can use a default constructor to set the default value of the property
or just have an empty setter on the property
public class PathNames {
private string _pathA = "Some Path";
private string _pathB = "Another Path";
public string BaseDirectoryPath {
get {
return Path.Combine(_pathA, _pathB);
}
set {
//No OP
}
}
}
You can see how creating a Custom ASP.NET Web Service.
Might you need to rebuild web service ASP.Net and add your assembly to the global assembly cache (GAC).
I hope this help you.

C# signalr data annontations

I would like to write method validation processes which will be similar to data annontations presented in Web API.
In web api we can validate an object, for example:
public class Numbers
{
[NumberOne]
public string Number1 { get; set; }
[NumberTwo]
public string Number2 { get; set; }
}
and as long as we define the attributes NumberOneAttribute and NumberTwoAttribute its gonna be ok.
The difference is that web api has access to the GlobalConfiguration.Configuration.Filters which it seems like signalr doesn't.
Is there anyway to validate requests by attributes? or I need to follow the worst case, validate each input in the invoked method?
Thanks,
Ori.
In SignalR 2.2.x there is no native way of achieving this, but there is a project on GitHub that that adds a Validation Module in the SignalR pipeline.
Basically, in order to use it, you add a new module to the pipeline:
GlobalHost.HubPipeline.AddModule(new ValidationModule());
Then, you can use attributes like [Required] for the models' properties and then decorate the desired methods with the [Validate] attribute.
Note that this is a proof of contept project.
Best regards!

Why do my WCF class names have the parent class as part of their name?

I've been experimenting with Silverlight-Enabled WCF services and I'm getting a strange behavior that doesn't happen in the tutorial I was using. I create a simple operation contract like such: (yes, I know there is no interface with everything defined, it's something that the Silverlight-enabled template does)
[ServiceContract(Namespace = "")]
[SilverlightFaultBehavior]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class TestService1
{
public class TestResponse
{
public string Hello { get; set; }
}
[OperationContract]
public TestResponse TestCall()
{
return new TestResponse();
}
}
Then I go and create a reference to it like I would a regular WCF service. But when I go to use my defined classes:
ServiceReference2.TestService1TestResponse test = new ServiceReference2.TestService1TestResponse();
Whereas I'm expecting ServiceReference2.TestResponse. Any idea why my parent class name is being concatenated onto the front of my datamember class names? I added a service reference to a plain console application and the same thing happens, so it's not a silverlight related thing.. maybe some setting in Silverlight-enabled WEC services? I watched this tutorial https://www.youtube.com/watch?v=8ln2LyWvf6Q to see if it happened for others, but it looks like the class names work fine there.
Out of luck I discovered what the issue was. I need to have the TestResponse class declared outside of the TestService1 class. I'm a little surprised the code generator for creating service references creates the classes in this way. I'd expect a ServiceReference2.TestService1.TestResponse instead, which is what threw me off so much.

SharePoint WebPart Custom Settings - Best Practise

I'm trying to ascertain what the best practise is for creating a SharePoint WebPart that has custom properties. I'll detail the background, because I might be doing this in completely the wrong way.
I've taken a DevExpress chart, which has a whole host of settings on there. I then decided to expose some of these settings and ended up with a WebPart that looked like:
public class MyWebPart : WebPart
{
public DataTable { get; set; }
public String ConnectionString { get; set; }
public String Query { get; set; }
public override void DataBind()
{
UpdateMyTable(ConnectionString, Query);
this.chartControl.DataSource = this.DataTable;
}
}
I needed to add a whole load more settings onto this web part, a few single items that are strings, and others that correspond to a series (e.g. Binding values, Chart Type). So I moved the settings off the WebPart and ended up with something more akin to the following:
public class MyWebPart : WebPart
{
public DataTable { get; set; }
public ChartSettings { get; set; }
public override void DataBind()
{
UpdateMyTable(ConnectionString, Query);
this.chartControl.DataSource = this.DataTable;
}
}
public ChartSettings
{
public List<SeriesSettings> Series { get; set; }
}
I made my settings classes Serializable and added a Personalizable attribute on the Property on my web part. This works fine via the web.
If I attempt to open the page in SharePoint designer however it complains that it can't create a ChartSettings (and DataTable) from their String representations. I've learnt that this is because the settings are exposed as Strings. Obviously the DataTable I can suppress the serialization of.
My question ultimately is, am I following the correct approach, moving settings onto a class? Or should I be leaving all the settings on my webpart (which would be messy keeping lots of series settings in different arrays), or is there a completely different approach? If you can point me to any references to support your suggestion (e.g. MSDN) then that would be very much appreciated.
My personal experience (and some may disagree) has been to keep the WebPart as thin as possible. WebParts seem to be awkward for things like: configuration, error handling and logging, tracing, etc. I have found it much easier to put the bulk of my development into a WS (WebService/WCF) on localhost:8080. The code in the webpart is simple: call the WS and let it do all of the work. Config in the webpart is now simple because localhost is always easy to find. Dev tools for WS/WCF are very strong. Config, debugging, error handling, logging, tracing are all much simpler in WS/WCF. Better still, I make a simple jig (Winform/Webform) to call/test my WS layer. With this architecture, you put your code where your dev tools are strongest. It is similar to the rationale behind the MVC pattern.

how to use your same Domain entities throug a .Net webservice?

if you have an entity which is reference in the client and a webservice like this
public class Post
{
public int ID {get; set;}
string Data {get; set;}
}
public class MyService: System.Web.Services.WebService
{
[WebMethod]
public int Write (Post post)
{
//Do stuff
}
}
on the client in order to use the entity you to instantiate from the proxy class
public void ClientMethod()
{
var post = new proxyclass.Post();
//fill post
new ProxyClass.Myservice().Write(post)
}
how can i use my domain entity to call the webservice?
public void ClientMethod()
{
var post = new Post();
//fill post
new ProxyClass.Myservice().Write(post)
}
Basically, you can't - with regular web-services, at least... the proxy class is completely separate. However, the above is possible with WCF, where you don't actually need proxy classes at all (however, for SOA purity it is a good idea to use them).
You could use reflection (etc) to copy the properties between your domain entities and the proxies, but it is quite hard to get this 100% right (although xml serialization should work [in theory] as an intermediate language).
So; if you want to use assembly sharing; consider using WCF, which supports this ;-p
To get hold of a service without using a proxy layer, you can do tricks like:
public class WcfClient<T> : ClientBase<T> where T : class
{
public T Service { get { return base.Channel; } }
}
(this will access the default configuration from the app.config; for more control you need to add a few constructor overloads matching to the base constructor overloads)
Then:
interface IFoo {void Bar();}
...
using(WcfClient<IFoo> client = new WcfClient<IFoo>()) {
client.Service.Bar();
}
I suspect that one of these might answer your qestion. The common theme is wsdl.exe /sharetypes and svcutil /reference.
Managing 2 web references with shared class dependency in a .NET project
Force .NET webservice to use local object class, not proxy class
.Net Consuming Web Service: Identical types in two different services
How to get a webserice to serialize/deserialize the same type in .net
.NET SOAP Common types
wsdl.exe /sharetypes
You should use WCF for new development whenever possible.
However, you should reconsider your reasons for wanting to use your domain class on the client. It does violate the principles of SOA by exposing to the client some details of the implementation of the service. Why should the client know anything about your entity classes, beyond the data that they contain?
For instance, your entity classes may contain methods to save the entity to the database. Why does your client need access to that method?
Also, one of the principals of SOA is to interoperate with different platforms. As soon as you require your client to use your (.NET) entity, you prevent a Java or PHP client from being written to use your service.
You may have good enough reasons to overcome such objections, but I recommend that you think it through and make sure your reasons are good enough.
For cases like this you're better to use json for sending and receiving data to and from web service.
Newtonsoft.json is the best json serializer for .Net. so you should change your Write method like below:
public void ClientMethod()
{
var post = new Post();
//fill post
new ProxyClass.Myservice().Write(JsonConvert.SerializeObject(post))
}

Categories

Resources