2

I've scoured the internet, several books, and even consulted some peers. Nothing really states if what I'm attempting to do is bad practice or not. The short; is I'm just doing a fire-and-forget from the client.

[ServiceContract]
public interface ICustomerInformation
{

       [OperationContract(IsOneWay = true, IsTerminating = true, IsInitiating = false)]
       ICustomerAccount GetCustomerDetails (string First);

}

[DataContract]
public interface ICustomerAccount
{
      _firstName = firstName;

      [DataMember]
      string FirstName 
      {
            get { return _firstName; }
            set { _firstName = value; }
      }
}

My original thought was an implementation similar to this to abstract the properties; so the server and application tied to the server could make use of these properties. But is that really a smart thing to do? Or even good practice?

My assumption was; by adding this layer to the service it will allow user interfaces accessing the service to simply push it's data; while allowing the functionality to tie straight into the data. So if a users data changes, the service will change it for the functionality on the server.

Is that a bad way to view? Or attempt this? Am I misguided on this interpretation?

Like I said above; the goal is a logical abstraction where multiple styles of interfaces push its data to the service. The service then takes the input; performs a function based on those variable input values.

If I've worded it poorly let me know so I can edit; or think of a better means of explanation. Any assistance would be great.


Update:

I'm trying to create a universal interface; where any application or client interface for that matter inputs data. Once the data is submitted to the service; the server takes it. No data needs to be returned; but the server just runs through commands utilizing the client side information.

Essentially, I'm attempting to make data universally pushed through the service for the server to do task. The client doesn't need to be aware of any of the server task that it's doing.

My thought process was to logically separate UI / user input through the service; then the service invokes server side functions with information it gathered from the user.

Example: Textbox(Name) --> Service --> Server stores Name as variable to perform a series of task: Write Name to database, name textfile by user name, and so on.

Greg
  • 11,302
  • 2
  • 48
  • 79
  • 1
    Could you be more clear about where you want to push the data from, and where it's being received (and possibly broadcast back to)? Also, are you trying to do something dynamic, like passing property names or something of the sort? – casperOne Nov 20 '12 at 20:34
  • I don't think your code will compile. You can't have fields in an interface. Also, you will probably get a runtime error when the DataContractSerializer tries to deserialize your contract and can't determine the class definition. You shouldn't use interfaces as DataContracts, only classes. – Josh C. Nov 20 '12 at 20:35
  • @JoshC.; there's ways to deal with the serialization issues related to interfaces as DataContracts, for example; http://msdn.microsoft.com/en-us/library/system.servicemodel.serviceknowntypeattribute.aspx – RJ Lohan Nov 20 '12 at 21:00
  • I'm confused as to what you are trying to achieve - 'fire and forget' with a method intended to retrieve data (GetCustomerInfo) doesn't sound right...? If you want service callbacks, you'll need to look at Duplex services (http://msdn.microsoft.com/en-us/library/ms731064.aspx). If you want to know if it's ok to send data to a server and not worry about a reply, that's fine too, you just might want to think about success/error handling. – RJ Lohan Nov 20 '12 at 21:03
  • I'm just simply pushing any client form data; multiple sites- applications- just push the data to the server. Once the server gets the code it actually will write data to it's database and run certain commands specific to the server based on users input. – Greg Nov 20 '12 at 21:23
  • Are you planning on having many methods on the service that each accept one parameter, with each method storing a particular property, or one method that accepts one parameter and based on the data passed, decides where it should save? – Sam Shiles Nov 20 '12 at 21:38
  • All I want is for any application to submit basic details: **First Name, Last Name, Email Address, Phone Number, Site Name, and State. ** Once that data is sent from any application; the servers empty variables will fill with those client side variables; then it will do the task provided utilizing its current variables just filled with client information. An example would be `Console.WriteLine(Name);` Would be null until the clients interface fires it's data then `Console.WriteLine(Name);` would trigger John, Steve, whatever name was used on client side. – Greg Nov 20 '12 at 21:46

1 Answers1

3

If I understand correctly, it seems like you want to implement some sort of message/command passing model, which seems completely legitimate to me. Take a look at this article for instance that talks about utilizing commands as architectural pattern. Those commands can be serialized over the wire from client to (WCF) service which allows you to create a highly maintainable service layer (as explained here). So back to your original question: yes this seems like a legitimate model to use. Though I would advise to read those articles. They might give you some more background on these kinds of models.

Steven
  • 166,672
  • 24
  • 332
  • 435