我搜索了互联网，几本书，甚至咨询了一些同行。没有什么能真正说明我正在尝试做的事情是否是不好的做法。短; 我只是在做客户的一劳永逸。
[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; }
}
}
我最初的想法是与此类似的实现来抽象属性；所以服务器和绑定到服务器的应用程序可以利用这些属性。但这真的是明智之举吗？甚至是好的做法？
我的假设是；通过将这一层添加到服务中，它将允许访问服务的用户界面简单地推送它的数据；同时允许功能直接绑定到数据中。因此，如果用户数据发生更改，服务将针对服务器上的功能对其进行更改。
这是一种不好的观看方式吗？或者尝试这个？我对这种解释有误导吗？
就像我上面说的；目标是一种逻辑抽象，其中多种样式的接口将其数据推送到服务。然后服务接受输入；根据这些可变输入值执行功能。
如果我措辞不好，请告诉我，以便我进行编辑；或者想一个更好的解释方式。任何帮助都会很棒。
更新：
我正在尝试创建一个通用接口；与此相关的任何应用程序或客户端接口输入数据的地方。一旦数据提交给服务；服务器接受它。无需返回数据；但服务器只是通过使用客户端信息的命令运行。
从本质上讲，我正在尝试通过服务普遍推送数据以供服务器执行任务。客户端不需要知道它正在执行的任何服务器任务。
我的想法是通过服务在逻辑上分离 UI/用户输入；然后服务使用从用户那里收集的信息调用服务器端功能。
示例：Textbox(Name) --> Service --> Server 将 Name 存储为变量以执行一系列任务：将 Name 写入数据库，通过用户名命名 textfile，等等。