这是我的第一个问题,它不是"我该怎么做"而更像是"最干净的方式",因为我看到了几种方法,但似乎没有一种方法对我很有吸引力.
这是一个要描述的复杂问题.基本上,我有一个添加/编辑视图,允许用户编辑某些对象的字段.这个对象非常复杂:它有一些字段,它有一个复杂对象的子列表.每个复杂对象大约有40个字段(主要是复选框,单选按钮和日期/时间).我已将此表示为选择列表:
http://fortheloot.com/public/pictures/sub-items.png
" 添加"按钮会生成包含各种字段的对话框.
问题来了.当用户接受对话框并关闭对话框时,我现在必须将此数据存储在某处,以便用户可以在实际提交表单之前进一步编辑或添加其他子项.
最明显的方法是为每个子对象创建一组隐藏字段.因此,添加子项会为元素添加40个隐藏元素<form>.添加10个子项目,您有400个隐藏字段.这将正常工作,如果字段名称正确,将绑定到此模型:
public class AddEditModel
{
[Display(Name = "ID")]
public int? Id { get; set; }
[Display(Name = "Name")]
[Required]
[StringLength(100)]
public string Name { get; set; }
public IList<EntryModel> Entries { get; set; }
public class EntryModel { /* fields */ }
}
在模型绑定方面,这似乎看起来很不错,但从客户端来说,我必须跟踪数百个DOM元素,这对我来说似乎很麻烦.从40个其他元素加载和卸载对话框的各种表单元素似乎......就像它可能更好.
理想情况下,我希望能够<option>使用data-HTML 5属性或jQuery data()函数将数据作为javascript对象存储在元素上,这些属性实际上是同一个.这将使javascript方面的东西更清晰,但它不会自动绑定到回发模型.
如果有一种方法可以充分利用这两个世界 - 在<option>元素上存储单个JS对象,或者甚至是单个<input type="hidden" />元素(每个子项) - 这仍然会在回发时正确绑定到模型,我会觉得这个问题解决了.
我有机会花费大量时间尝试在单声道中使用WCF.对于玩具应用之外的任何东西,此时实施起来实施得太差,无法投入生产环境.它不能在24/7负载下存活.
我目前在生产环境中运行Mono上的WCF,但我需要远离它,至少在近期内,为我的软件带来稳定性.目前,我通过每隔几个小时重新启动进程而幸存下来,而这往往是不够的.
我正在寻找潜在的替代品.我的所有通信实体都是基于.net的,其中一些是Linux上的Mono,另一些是Windows Server上的ms.net.我很想用protobuf-net作为序列化层来推广我自己的RPC 层,但我不想这样做.protobuf-net的一大优点是它具有良好的C++支持,这是我重视的东西.
有没有人在Mono上实现RPC的稳定性？如果是这样,你做了什么？
更新:我没有提到我正在寻找有状态的双工消息.这是一个非常重要的信息.我并没有坚持下去,但我非常想要它.WCF为此提供net-tcp双工通道.
一些背景:
我有一个依赖第三方硬件和闭源驱动程序的应用程序.驱动程序当前有一个错误导致设备在一段随机时间后停止响应.这是由于驱动程序中存在明显的死锁并中断了我的应用程序的正常运行,这是一个始终在24/7高度可见的环境.
我发现将GDB附加到进程,并立即从进程中分离GDB导致设备恢复功能.这是我第一次表明驱动程序本身存在线程锁定问题.存在某种导致僵局的竞争条件.附加GDB显然会导致一些线程重新调整,并可能将它们推出等待状态,导致它们重新评估其状态,从而打破僵局.
问题:
我的问题很简单:是否有一个干净的等待应用程序触发程序中的所有线程来中断其等待状态？确实有效的一件事(至少在我的实现上)是发送一个SIGSTOP,紧接着是来自另一个进程的SIGCONT(即来自bash):
kill -19 `cat /var/run/mypidfile` ; kill -18 `cat /var/run/mypidfile`
这会触发过程中的虚假唤醒,一切都恢复了生机.
我希望有一种智能方法可以触发我进程中所有线程的虚假唤醒.想想pthread_cond_broadcast(...)但无法访问等待的实际条件变量.
这是可能的,还是依赖于kill我唯一的方法？
我在双工通道上有一个WCF服务,带有回调契约.OperationContext.Current.GetCallbackChannel<T>()当客户端调用SubscribeMe()服务上的方法时,服务通过将结果存储在列表中来跟踪客户端.该服务将定期ping这些回调通道以跟踪其有效性,并使那些关闭或超时的通话到期.
我的问题是:当远程主机没有主动向我的服务请求时,如何获取有关远程主机的信息,例如当我打电话时MyCallbackContract.Ping()？
我尝试将回调通道对象转换为IContextChannel并访问该 IContextChannel::RemoteAddress属性,但此属性包含某种与回调通道上的实际远程主机无关的命名空间URI.