blocks|key|2273084|text|不幸的是，如果不以某种方式标记构造函数，在.NET中这是不可能的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2273085|为程序集元数据中的每个构造函数存储的方法签名仅包含构造函数的每个参数的类型。任何.NET+ORM都不可能真正知道使用哪个构造函数。ORM看到的都是这样的东西：|2273086|.ctor()
.ctor(string,+string)
.ctor(string,+string,+string)|code-block|syntax|javascript|2273087|ORM无法知道哪个.ctor参数对应于客户对象的FirstName、LastName和MiddleName。|2273088|为了提供这种支持，.NET+ORM必须支持读取您为每个参数定义的自定义属性。您需要像这样标记构造函数：|2273089|公共客户(属性(“FirstName”)字符串FirstName，属性(“LastName”)字符串LastName，属性(“MiddleName”)字符串MiddleName)|2273090|这有两个缺点：|2273091|没有办法(我可以想到，可能有人会纠正我)，这可以进入一个映射文件。|ordered-list-item|2273092|您仍然需要编写与以前一样的映射，因为ORM仍然需要能够为每个属性获取单独的值。|2273093|因此，您需要做所有这些额外的工作，标记构造函数，同时，您仍然需要像以前一样映射您的类。|2273094|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|11|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|12|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|13|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|14|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|15|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|16|8|@]|9|@]|A|$]]|$1|T|3|U|5|S|7|17|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|18|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|Y|$]]

Unfortunately this is impossible in .NET without you marking up the constructors in some way.

The method signature stored for each constructor in the assembly metadata only contains the type of each parameter to the constructor. There's no way for ANY .NET ORM to really know which constructor to use. All the ORM sees is something like this:

<pre><code>.ctor()
.ctor(string, string)
.ctor(string, string, string)
</code></pre>

There's no way for the ORM to know which .ctor parameter corresponds to the FirstName, LastName and MiddleName for your Customer object for instance.

In order to give you this support, a .NET ORM must support reading in custom attributes that you define for each parameter. You'd need to markup your constructors like this:

public Customer([Property("FirstName")] string FirstName, [Property("LastName")] string LastName, [Property("MiddleName")] string MiddleName)

This has 2 disadvantages:

<ol>
<li>There is no way (that I can think of, someone will probably correct me), that this can go into a mapping file. </li>
<li>You'd still need to write the same mapping as you've always done, because the ORM still needs to be able to get individual values for each property.</li>
</ol>

So you'd need to do all this extra work marking up the constructors and at the same time, you'd still need to map your classes EXACTLY as you were doing before.

blocks|key|906173|text|我认为大多数ORM实际上支持这个概念，至少DataObject.Net支持这个概念。此代码如预期的那样工作：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|906174|[HierarchyRoot(typeof(KeyGenerator),+"Id")]
public+class+Message+:+Entity
{
++[Field]
++public+int+Id+{+get;+private+set;+}

++[Field(Length+=+100)]
++public+string+Text+{+get;+private+set;+}

++public+Message(string+Text)
++{
++++Text+=+text;
++}
}|code-block|syntax|javascript|906175|编辑：+DataObjects将数据存储在内部事务状态，并使用PostSharp生成的特殊物化构造函数。当然，如果ORM使用poco对象，也不是那么简单。|offset|length|style|BOLD|906176|entityMap^0|0|0|0|3|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I think most of ORMs actually support this concept, at least DataObject.Net does. This code works as it expected:

<pre><code>[HierarchyRoot(typeof(KeyGenerator), "Id")]
public class Message : Entity
{
 [Field]
 public int Id { get; private set; }

 [Field(Length = 100)]
 public string Text { get; private set; }

 public Message(string Text)
 {
 Text = text;
 }
}
</code></pre>

EDIT: DataObjects store data in internal transactional state, and use special materialization constructor, generated by PostSharp. Of course it is not so trivial if ORM use poco objects.

blocks|key|906193|text|这取决于您认为不应该更改的值。自动增量、计算列等都是很好的候选项。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|906194|当然，我使用我编写的ORM，如果您试图设置只读属性的值，它会引发异常。|906195|更新：|offset|length|style|BOLD|906196|记住，构造函数也用于持久化数据。让对象在构造函数中接受PK(s)是一种常见的模式，它将自动获取该记录。|906197|entityMap^0|0|0|0|3|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@$F|Q|G|R|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

That depends what you consider values that should not be changed. Autoincrements, calculated columns, etc., are good candidates for this.

It is certainly possible, I use an ORM that I wrote, and it throws an exception if you attempt to set the value of a read-only property.

Update:

Remember constructors are used for persisted data as well. It is a common pattern to have your object accept the PK(s) in the constructor, and it will automatically fetch that record.

blocks|key|2273165|text|通常情况下，OR映射程序不可能只使用构造函数。假设一个由传递给构造函数的值初始化的对象，然后通过方法调用修改状态。在这种情况下，对象可能持久化为无效的初始状态，因此被构造函数拒绝。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2273166|因此，也许有这样一个或映射器，但它肯定会有局限性。正如给出的示例所说明的，我不认为绕过OR映射器封装对象是糟糕的设计，而是某些情况下的需求。|2273167|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It is - in the general case - not possible for an OR mapper to only use constructors. Assume a object that is initialized by the values passed to the constructor and after that the state is modified by method calls. In this case the object might be persisted with a state that is no valid initial state and hence rejected by the constructor.

So there might by such a OR mapper, but it will definitly have limitations. As illustrate by the given example I would not consider bypassing the object encapsulation by an OR mapper as bad design, but as a requirement in some situations.

blocks|key|749063|text|你为什么觉得这感觉不对？您希望您的OR/M在重构对象时执行业务逻辑吗？IMHO，不。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|749064|当您从DB加载对象时，无论发生什么，OR/M都应该能够重构该对象。在重新计算时设置一些值，不应该导致触发某种改变另一个值的逻辑(+ORM也应该给一个值.)|749065|即使如此，我认为构造函数应该只包含那些在对象创建时必须使对象处于“有效”状态的字段的参数。其次，您可能有一些计算给出的值的公共只读属性，这些属性也需要持久化。|749066|如果你觉得反射是重建物体的一种“气味”，你将如何处理这种情况？您必须以某种方式创建一个公共方法，该方法可以设置“只读”值，但这会破坏封装，而且您也不会这样做。|749067|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Why do you think this feels wrong ?
Do you want your OR/M to perform business logic when reconstituting an object ? IMHO, no.

When you load an object from the DB, then the OR/M should be able to reconstitute the object, no matter what. Setting some value while reconsituting, should not lead to trigger some kind of logic that changes another value (that maybe should be given a value by the ORM as well ... )

Even so, I think a constructor should only contain parameters for those fields that are mandatory at object-creation time to have the object in a 'valid' state.
Next to that, you might have public read-only properties that have been given a value by some calculation, and that need to be persisted as well. 
If you feel reflection is a 'smell' to reconstitute objects, how are you going to deal with this situation ? You'll have to somehow create a public method which would be able to set that 'read only' value, but this breaks encapsulation, and you don't wan't that either.

blocks|key|749088|text|不久前，斯基特提出了一种“建筑商”模式。我把它变成了POCO课程中的一个公共课程。它具有与POCO相同的属性，但都是读/写的。POCO在必要的地方是只读的，但是是私有的。这样，当POCO被实例化并且构造函数没有时髦的args时，构建器就可以设置属性。就像“冰棒不变”一样。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|749089|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Mr. Skeet suggested a 'builder' pattern a while ago. I made it a public class within the POCO class. It has the same properties as POCO, but all read/write. POCO is readonly where necessary, but PRIVATE SET. That way the builder can set the properites when the POCO is instantiated and not have funky args for a constructor. Kind of 'popcicle immutability' there.

blocks|key|2273267|text|我同意前面的招贴画之一，即构造函数应该用于在对象生命周期开始时创建对象。使用构造函数对当前处于存档状态的现有对象进行水合物充其量是违反直觉的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2273268|需要考虑的是，在这一点上，所有主要的ORM似乎都缺少的是，从存储在数据库或任何其他数据存储区中的最后一个已知状态重新构成域对象，本质上并不是一个构造或修改操作；因此，不应该使用构造函数或属性设置器。相反，与这种操作最密切对应的框架机制是序列化！已经有一些可识别的模式可用于存储对象的状态，然后再通过ISerializable接口、标准序列化构造函数等对其进行重构。将对象持久化到数据库与将对象持久化到流根本没有区别；实际上，序列化期间使用的StreamingContextStates枚举的值之一是持久性！IMHO，这应该是设计任何持久性机制时的标准方法。不幸的是，我不知道有任何ORM支持这一点。|2273269|还应该注意的是，为序列化而设计的对象仍然是POCO；持久性无知并没有被违反。这里的关键点是，域对象应该最清楚地知道持久化和恢复它所需的数据，以及数据应该按照什么顺序恢复(这通常很重要)。对象不需要知道存储它的具体机制:关系数据库、平面文件、二进制blob等等。|2273270|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I agree with one of the previous posters that constructors should be for creating an object at the beginning of its lifetime. Using a constructor to hydrate an existing object that is currently in an archived state is counter-intuitive at best.

What needs to be considered, and what all major ORMs seem to be missing at this point, is that re-constituting a domain object from its last known state, as stored in a database or any other data store, is NOT inherently a constructing or modifying operation; so neither constructors or property setters should be used. Rather, the framework mechanism that most closely corresponds to this kind of operation is serialization! There are already recognized patterns for storing an object's state and then later reconstituting it through the ISerializable interface, the standard serialization constructor, etc. Persisting an object to a database is fundamentally no different from persisting it to a stream; in fact, one of the values of the StreamingContextStates enumeration that is used during serialization is Persistence!. IMHO, this should be the standard approach when designing any persistence mechanism. Unfortunately, I don't know of any ORM that supports this out of the box.

It should also be noted that an object that has been designed for serialization is still POCO; persistence ignorance has NOT been violated. The key point here is that a domain object should know best what data is needed to persist and restore it, as well as in what order that data should be restored (which often matters). What the object should NOT have to know is the specific mechanism by which it will be stored: relational database, flat file, binary blob, etc.

blocks|key|749168|text|我想我知道了！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|749169|感谢大家的投入，但我必须回答我自己的问题。我只是花了一个多小时来研究PoEAA目录，思考OO原则，并将其与对C#语言和.NET框架的深入思考结合在一起。|offset|length|749170|我想出的答案是，one需要使用构造函数解决不了问题，最终与构造函数本身没有关系。我是懒惰加载！|style|BOLD|749171|基本上，如果不实现域类中的延迟加载(对于持久化、无知和灵活性来说，这是一个主要的no-no+)，如果不对域类进行子类分类，就无法做到这一点。这个子类是NHibernate需要虚拟属性的原因。|749172|我仍然认为使用构造函数而不是反射或其他方法填充父类的字段会更好(至少对于非集合.延迟加载确实有其位置)，但我肯定看到了no-arg构造函数的位置。|749173|entityMap|0|LINK|mutability|MUTABLE|url|http://martinfowler.com/eaaCatalog/|1|http://en.wikipedia.org/wiki/Lazy_loading^0|0|Y|7|0|0|8|3|16|4|1|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|F|3|G|5|6|7|12|8|@$D|13|E|14|H|I]]|9|@$D|15|E|16|1|17]]|A|$]]|$1|J|3|K|5|6|7|18|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|19|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]|V|$5|Q|R|S|A|$T|W]]]]

By Jove, I think I've got it! 

Thanks to everyone for their input, but I'm going to have to answer my own question. I just spent an hour or so digging through the <a href="http://martinfowler.com/eaaCatalog/" rel="nofollow noreferrer">PoEAA catalog</a>, contemplating OO principles, and mixing that in with deep thought about the C# language and the .NET framework.

The answer I came up with, the one need that I couldn't solve properly using constructors, ends up not being related to the constructor itself in the end. It's <a href="http://en.wikipedia.org/wiki/Lazy_loading" rel="nofollow noreferrer">lazy loading</a>! 

Basically, without implementing the lazy loading inside your domain classes (a major no-no for persistence ignorance and flexibility), there's no way to do it without subclassing the domain classes. This subclassing is the reason that NHibernate requires virtual properties. 

I still think that utilizing a constructor rather than reflection or some other method to populate the fields of the parent class would be better (at least for non-collections...lazy loading does have its place), but I definitely see where the no-arg constructor has its place.

This is related conceptually to my question <a href="https://stackoverflow.com/questions/826872/orms-and-constructors">here</a>. However, I've been playing around with NHibernate, and realized what the real core of my question is. 

In classic OO design, to properly encapsulate data, it's a common pattern to have values passed in to an object's constructor that are stored in data members (fields). Those values which should not be changed are exposed with only accessors (read-only properties). Those which it is permissible to change have both accessors and mutators (read-write properties). It seems to me that a proper O/RM should respect these conventions, and use the available constructors when creating an object. Relying on read-write properties, reflection, or other, hackish (IMHO) methods seems...wrong.

Is there a .NET O/RM solution out there that does this?

EDIT

To address Praveen's point, I know that there are projects that have a 'default' algorithm for choosing a constructor - StructureMap, for example, always uses the constructor with the most arguments, unless you mark a constructor with a custom attribute. I can see this being an effective way handle the situation. Perhaps utilizing an IoC container in addition to the ORM would provide the sort of solution I'm needing - though it seems to me that this is, while not inherently bad, an unnecessary additional step for using an ORM.

Do any .NET ORMs use constructors "properly"?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

这在概念上与我的问题有关。然而，我一直在玩NHibernate，并且意识到我问题的真正核心是什么。在典型的OO设计中，为了正确地封装数据，将值传递给存储在数据成员(字段)中的对象的构造函数是一种常见的模式。那些不应该更改的值只公开了访问器(只读属性)。允许更改的对象同时具有访问器和修改器(读-写属性)。在我看来，适当的...

问是否有任何.NET程序“正确”使用构造函数？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否有任何.NET程序“正确”使用构造函数？EN