这是允许的:
int a, b, c;
a = b = c = 16;
string s = null;
while ((s = "Hello") != null) ;
根据我的理解,赋值s = ”Hello”;只“Hello”应该分配给s,但操作不应该返回任何值.如果这是真的,那么((s = "Hello") != null)就会产生错误,因为它null会与任何东西相比较.
允许赋值语句返回值的原因是什么？
UTF-8可以包含BOM.但是,它对字节流的字节顺序没有影响.UTF-8始终具有相同的字节顺序.
如果Utf-8将所有代码点存储在单个字节中,那么为什么字节顺序不起任何作用BOM是有道理的,因此不需要为什么.但是,由于代码点128及以上使用2,3和最多6个字节存储,这意味着它们在大端机器上的字节顺序与小端机器上的字节顺序不同,那么我们如何声称Utf-8总是具有相同的字节顺序？
谢谢
编辑:
UTF-8是面向字节的
据我所知,如果两个字节UTF-8字符C由字节B1和B2组成(其中B1第一个字节B2是最后一个字节),那么UTF-8这两个字节总是以相同的顺序写入(因此如果将此字符写入小端机器上的文件LEM,B1将是第一个也是B2最后一个.同样,如果C写入大端机器上的文件BEM,B1仍将是第一个B2仍然是最后一个).
但是,当发生了什么C写入到文件F上LEM,但我们复制F到BEM设法在那里读了吗？由于BEM自动交换字节(B1现在是最后B2一个字节和第一个字节),app(运行BEM)读取如何F知道是否创建了F BEM,因此没有交换两个字节的顺序或是否F从中转移LEM,在这种情况下BEM自动交换字节？
我希望问题有道理
编辑2:
响应您的编辑:如果要求大端机器一次读取一个字节,则不会交换字节.
a)哦,所以即使字符C是2个字节长,app(驻留在BEM上)读取F会在当时只读一个字节读入存储器(因此它将首先读入存储器B1,然后才读入B2 …
方法重载允许我们定义许多具有相同名称但具有不同参数集的方法(因此具有相同的名称但不同的签名).
这两种方法是否超载？
class A
{
public static void MyMethod<T>(T myVal) { }
public static void MyMethod(int myVal) { }
}
编辑:
不应该声明A<int>.MyMethod(myInt);抛出错误,因为构造类型A<int>有两个具有相同名称和相同签名的方法？
static void Main(string[] args)
{
List<int> listArray = new List<int>();
listArray.Add(100);
foreach (int item in listArray)
Console.WriteLine(item);
}
a)在foreach声明中呼吁listArray's IEnumerable<int>.GetEnumerator()实现,它通过调用它listArray.GetEnumerator()或IEnumerable<int>.GetEnumerator()或 IEnumerable.GetEnumerator()？
b)同样,当foreach引用对象返回时listArray's IEnumerable<int>.GetEnumerator(),它是通过引用IEnumerator还是IEnumerator<int>引用类型引用该对象？
谢谢
编辑:
我的一些问题将引用此文:
o使用标识符GetEnumerator对类型X执行成员查找,而不使用类型参数.如果成员查找不产生匹配,或者产生歧义,或产生不是方法组的匹配,请检查可枚举接口,如下所述.如果成员查找产生除方法组或不匹配之外的任何内容,建议发出警告.
o使用生成的方法组和空参数列表执行重载解析.如果重载决策导致没有适用的方法,导致歧义,或导致单个最佳方法但该方法是静态的或不公开的,请检查可枚举的接口,如下所述.如果重载决策产生除明确的公共实例方法或没有适用的方法之外的任何内容,建议发出警告.
o如果GetEnumerator方法的返回类型E不是类,结构或接口类型,则会产生错误,并且不会采取进一步的步骤.
o在E上执行成员查找,标识符为Current,没有类型参数.如果成员查找不产生匹配,则结果是错误,或者结果是除允许读取的公共实例属性之外的任何内容,产生错误并且不执行进一步的步骤.
o成员查找在E上执行,标识符为MoveNext,没有类型参数.如果成员查找不产生匹配,则结果是错误,或者结果是除方法组之外的任何内容,产生错误并且不执行进一步的步骤.
o使用空参数列表对方法组执行重载分辨率.如果重载决策导致没有适用的方法,导致歧义,或导致单个最佳方法但该方法是静态的或非公共的,或者其返回类型不是bool,则产生错误并且不采取进一步的步骤.
o集合类型为X,枚举器类型为E,元素类型为Current属性的类型.
否则,检查一个可枚举的接口:o如果只有一个类型T,从而存在从X到接口System.Collections.Generic.IEnumerable的隐式转换,那么集合类型就是这个接口,枚举器类型就是接口System.Collections.Generic.IEnumerator,元素类型为T.
否则,如果存在多个这样的类型T,则产生错误并且不采取进一步的步骤.
否则,如果存在从X到System.Collections.IEnumerable接口的隐式转换,则集合类型为此接口,枚举器类型为接口System.Collections.IEnumerator,元素类型为object.
否则,将产生错误,并且不会采取进一步的步骤.
1)
引自Eric Lippert:
选项(1)是正确的.请注意,这意味着返回的枚举器是一个未装箱的可变结构.
事实上,这是一个可变的结构,如果你做一些愚蠢的事情,比如传递结构,就像它是一个引用类型一样,它具有非常实际的效果; 它将按值复制,而不是通过引用复制.
来自http://en.csharp-online.net/ECMA-334:_15.8.4_The_foreach_statement:
foreach(V v in x)嵌入式语句
然后扩展到:
Run Code Online (Sandbox Code Playgroud){ E e = ((C)(x)).GetEnumerator(); try { V v; while (e.MoveNext()) { …
-sky switch指定主题的键类型,它必须是签名,交换或表示提供者类型的整数.默认情况下,您可以为交换密钥传递1,为签名密钥传递2.
如果我理解正确,那么signature它exchange是两个关键类型？在什么情况下每个使用？
谢谢
a)我有点疑惑,在大多数情况下,我们是否应该只有一个生产整个Aggregate的工厂,还是我们还应该有一个仅创建Aggregate root的工厂？
b)如果一个工厂,构建整个集合构建两个根和非根单独的对象,还是应该委托建设非根实体/虚拟组织给其他工厂？
因此,如果Aggregate包含5种不同类型的非根实体,那么Aggregate factory应该自己创建这些非root实体,还是应该有另外5个工厂(每个非root实体有一个工厂),Aggregate工厂将委托给它们创建特定类型的非根实体？
谢谢
我正在阅读一本关于WCF的书和作者关于使用传输级安全性使用消息级安全性的优点的辩论.无论如何,我在作者的论点中找不到任何逻辑
传输安全性的一个限制是它依赖于网络路径中的每个"步骤"和参与者具有始终如一的安全性.换句话说,如果消息必须在到达其目的地之前通过中间人传播,则无法确保在中间人之后为该步骤启用传输安全性(除非该中间人完全由原始服务提供商控制) .如果不忠实地再现该安全性,则数据可能在下游受到损害.
消息安全侧重于确保单个消息的完整性和隐私性,而不考虑网络.通过加密和通过公钥和私钥签名等机制,即使通过不受保护的传输(例如普通HTTP)发送,该消息也将受到保护.
一个)
如果不忠实地再现该安全性,则数据可能在下游受到损害.
是的,但是假设两个系统通信使用SSL并因此使用证书,那么他们交换的数据不能被中间人解密,而是只能改变它,接收者会注意到并因此拒绝数据包？!
b)无论如何,据我所知,上述引用,暗示如果两个系统建立SSL连接,并且如果中间系统S启用了SSL并且如果S也是黑客拥有,那么S(也就是黑客)将不会能够拦截通过它的SSL流量吗？但如果S没有启用SSL,那么黑客将能够拦截SSL流量？这没有意义!
C)
消息安全侧重于确保单个消息的完整性和隐私性,而不考虑网络.通过加密和通过公钥和私钥签名等机制,即使通过不受保护的传输(例如普通HTTP)发送,该消息也将受到保护.
这没有意义,因为传输级安全性也可以使用加密和证书,那么为什么在消息级别使用私钥/公钥比在传输级别使用它们更安全呢？也就是说,如果中间人能够拦截SSL流量,为什么它也不能拦截通过消息级私有/公共密钥保护的消息？
谢谢
1)当应用程序使用存储库(基础结构服务)时,则存储库接口在域层中定义,而其实现在基础架构层中定义,因为域模型没有传出依赖关系.
a)如果我们100%确定域层内的任何代码都不会调用特定的(非存储库)基础设施服务 InfServ,那么我认为不需要在域层内定义InfServ的接口？
2)假设域层内的代码不会调用InfServ(因此我们不需要在Domain层中定义其接口):
a)如果应用层的服务将调用InfServ,我假设应用层应该对Infrastructure层有一个隐含的依赖,而不是相反？换句话说,无论InfServ的接口和它的实现应在中定义的基础设施层？
b)为什么Application层更好地依赖于Infrastructure层而不是其他方式,这是因为Infrastructure层可以被许多应用程序重用,而Application层在大多数情况下只针对单个应用程序而且通常其他应用程序无法重用？
c)如果我们100%确定Domain层中的代码不会使用Repository,那么我们不需要在Domain层中定义它的接口吗？
更新:
1)
是的,但是域层的定义可以包括充当域的外观的应用程序服务.应用程序服务通常引用存储库和其他基础结构服务.它协调域对象和所述服务以实现用例.
一个)
......充当领域的门面
难道我们不能说"常规"(我在问题中提到的那些)应用服务也可以作为域名的外观吗？
b)
应用程序服务通常引用存储库和其他基础结构服务.
从您的回复中看起来好像您建议(虽然您可能不是)"常规" 应用服务通常不会引用基础设施服务,实际上他们这样做(据我所知)？!
2)
一个)
我通常将应用程序服务(如上所述)合并到域层中.
"常规" …
嗯,我完全迷失了所以任何帮助都会受到赞赏
OperationContext.Current.InstanceContext是传入通道正在使用的当前服务实例的上下文.
在双工系统中,服务可以通过CallbackContract回调客户端.此CallbackContract非常类似于客户端上的服务,该服务正在侦听客户端已打开的通道上的服务的调用.此"客户端回调服务"只能通过其在服务上使用的相同通道进行访问,因此只有该服务才能访问它.
a)因此,在双工系统中,客户端也使用与客户端向服务发送消息的相同通道实例来接收来自服务的消息？
b)如果在请求 - 回复系统中客户端使用特定的通道实例clientChannel向服务发送消息,那么我假设同一实例(因此clientChannel)需要保持打开,直到服务向此实例发送回复,而在双工系统clientChannel需要时在会议结束前保持开放状态？
c)我假设这样的行为,因为据我所知,每个频道实例都有一个唯一的地址(或ID),这有助于区分它在同一客户端上运行的其他频道实例？当服务发回消息时,它还指定了该频道的ID？
因此,当双工系统客户端调用服务时,WCF(在客户端)创建clientChannel一个通过线路发送消息的通道实例.在服务器端,WCF创建通道实例serverChannel,该实例将消息传递给请求的操作(方法).当此方法想要通过回调到客户端时CallbackContract,它用于InstanceContext.GetCallBackChannel<>创建一个通道,其中包含调用服务的通道的ID(因此它包含确切的地址或ID clientChannel)？
d)双工系统客户端是否使用相同的通道实例来调用任何端点的操作？
谢谢
1)
埃文的书,pg.415:
此外,域模型的关键方面可能跨越多个有界上下文,但根据定义,这些不同的模型无法构建以显示其共同焦点.
a)我假设引用暗示Core Domain CD可以跨越几个有界上下文 BC？
B)我假设的BC内CD应该只包含核心要素,但没有通用的元素？如果是这样,那是不是意味着我们应该始终设计具有核心域的BC(CD包含的那些)？换句话说,在我们开始设计BC之前,我们应该对CD是什么有一些大概的了解？
C)
......但根据定义,这些不同的模型无法构建以显示其共同焦点
我意识到BC不应该被构造成外部世界能够立即弄清楚所有部分(即BC)如何组合在一起以及它们的共同目的是什么,但是作者暗示这样的结构(它会隐含地传达)不同的BC的共同目的即使偶然也不会发生？如果是这样,为什么？
2)域模型可能有几个通用子域 GS,但是单个GS可以跨多个 BC吗？
更新:
1)
b)
我假设CD中的BCs应该只包含核心元素,但没有通用元素？...
人们当然应该知道在定义BC时核心域是什么.如上所述,理想情况下,它们应该是一对一的.然而,可以定义BC以满足处于非理想状态的系统的需要.
我假设你暗示在非理想情况下,CD中的BC也可能包含一些非核心元素,而且在非理想情况下CD可能包含多个BC？
C)
域跨越多个BC但是尽管有明确的边界,域行为当然可以跨越BC.上下文映射可以描述这种跨BC交互.引用本身基于域视觉声明的概念,其目的是突出核心域的价值并可能解释与BC的关系.
但是,为什么作者使用" 按定义 " 这个术语,好像暗示不可能意外地将BC结构化以使他们能够展示他们的共同焦点？
2)
域模型可能有几个通用子域GS,但是单个GS可以跨多个BC吗？
多个BC可以使用单个通用子域.我会避免使用术语"跨度",因为这过分强调了通用子域对整个域模型的重要性. …