Services expose methods (Operation Contracts) to the client. Your interface doesn't have any methods, so there's nothing to implement (from a service perspective).
You could do something like this:
[ServiceContract]
public interface INewUser
{
[OperationContract]
UserInfo CreateNewUser(string userName);
}
Then in the implementing class, you'd have:
public NewUser : INewUser
{
public UserInfo CreateNewUser(string userName)
{
return new UserInfo() {
UserName = "John Doe",
UserRole = 5,
LoweredUserName = "john doe"
};
}
}
UserInfo
would be the class used to represent the info, per your original code, marked as a data contract:
[DataContract]
public class UserInfo
{
[DataMember]
public string UserName { get; set; }
[DataMember]
public int UserRole { get; set; }
[DataMember]
public string LoweredUserName { get; set; }
}
This is a trivial example based on your above code, to show you how it can all go together.
HOWEVER
What you really should do is look at your existing library, wrap the functionality in a WCF service, and mark the NewUser
class up as a data contract. It looks like you're focusing on the data, and you should first focus on the functionality.
Put another way, what methods in your current library use NewUser
, as either inputs or return types - that is what goes into the service, not the properties of the NewUser
class.