如何在模型结构上表示必填业务字段？
如果我们使用类型提示，我们可以强制放置一个对象：
public function myMethodThatDoFineStuff(MyObject $myobject) {
}
如果我们不想放置所有对象而只是它的一些属性，那么该怎么办？ ？让我们假设我们的领域模型会更好，如果它能更好地代表某个领域。这对我们的业务模型（在我们的领域）是否更有意义？我们应该怎么做呢？
无论如何，我们应该始终放置所有对象吗？
用于澄清的示例建议：
让我们想象一下，为了列出某个作者的书籍，我们有这个方法：
public function listBookOfAuthor(Author $author) {
}
现在，让我们想象作者对象有 200 个左右的属性，但是，为了处理书籍列表，我们只需要它们的名字和姓氏。
无论如何，我们应该接收 ALL $author 对象吗？
If we use type hinting, we can place an object mandatory:
public function myMethodThatDoFineStuff(MyObject $myobject) {
}
What if, we would like to place, not the all object but only some of it's attributes, to be mandatory ? Let's assume that our domain model will be better, if it better represents a certain domain.If this could make more sense on our business model (on our domain)? How should we do it ?
Our should we always place the ALL Object no matter what ?
EXAMPLE for clarification proposes:
Let's imagine that, in order to list books of a certain author we have this method:
public function listBookOfAuthor(Author $author) {
}
Now, let's imagine that the author object has 200 properties or so, BUT, in order to process the list of books, we only need their first and last name.
Should we receive the ALL $author object anyway ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我将通过以下方式测试所需的属性：
如果您发现自己做了很多事情，您可以编写某种父类，其中包含用于检查属性是否存在的方法。
I would test for required properties in the following way:
If you find you're doing this lots you could write some kind of parent class that includes a method for checking properties are present.
从技术上讲，您可以创建一个仅包含函数期望的某些属性的接口。单独来看，这可能看起来有点像开销，但接口值得尝试一下，更多内容请参阅手册它们如何在 PHP 中工作。
我对你的商业模式一无所知，所以我不能说它是否有意义。但我认为你问的是编程问题而不是业务问题。
然后你将失去类型提示，但你将能够传递任何对象。取决于您想编写代码的严格程度。如果您使用接口，则在重构代码（更改具体对象实现）以及使用 stclass 对象时会非常灵活。然而，对于 stdclass 对象，函数需要在处理函数输入之前首先验证它得到的内容。
Technically you can create an interface with only those some attributes the function expects. Isolated this might look a bit like overhead but Interfaces are worth to play around a bit with, more in the manual how they work in PHP.
I know nothing about your business model, so I can't say if it makes sense or not. But I thought you were asking a programming question not a business one.
Then you'll loose type hinting but you will be able to pass any object. Depends a bit how strict you want to write your code. If you use interfaces you're pretty flexible when refactoring the code (changing concrete object implementations), as well as with the stclass object. However with the stdclass object the function needs to verify what it get's first before processing on the functions input.
根据您的架构，方法
listBooksOfAuthor()（看起来像BookService等服务对象上的方法）可能只需要一个$authorId，不是完整的Author对象。但我想我理解问题的要点。也许完全填充
Author对象的成本很高 - 例如，通过像AuthorService::getAuthorById()这样的方法。对于那些您需要的只是
Author功能的适度子集的情况，那么也许您可以创建一个独特的接口 - 可能类似于 AuthorSummaryInterface - 只反映您在这些情况下需要的那些方法。允许Author对象实现该接口，以便当您手头已有Author对象时，您可以执行仅需要该有限Author的操作> 功能。或者，您可以创建一个返回AuthorSummaryInterface的具体实现的方法Author:getSummary()。在此方法中，您可以强制执行您的成员要求（例如必须有一个名称），并在未满足这些要求时抛出异常。您还可以创建一组方法（可能在
AuthorService对象或AuthorSummaryService对象上），以生成AuthorSummary对象。然后，在只需要AuthorSummaryInterface功能的情况下，您可以创建这些功能有限、创建成本较低的对象。只是一些想法。
Depending upon your schema, the method
listBooksOfAuthor()(which looks like a method on a service object likeBookService) could probably suffice with only an$authorId, not a fullAuthorobject.But I think I understand the point of question. Perhaps the
Authorobject is expensive to fully populate - say, from a method likeAuthorService::getAuthorById().For those circumstances when all you need is a modest subset of
Authorfunctionality, then perhaps you could create a distinct interface - maybe something like AuthorSummaryInterface - that reflects only those methods you need for those circumstances. Allow theAuthorobject to implement that interface so that when you already have anAuthorobject in hand, you can perform operations that only require that limitedAuthorfunctionality. Alternatively, you could create a methodAuthor:getSummary()that returns a concrete implementation ofAuthorSummaryInterface. In this method, you could enforce your member requirements - must have a name, for exmaple - and throw an exception when those requirements are not fulfilled.You might also create a set of methods - perhaps on an
AuthorServiceobject or anAuthorSummaryServiceobject - that produceAuthorSummaryobjects. Then in those circumstances where onlyAuthorSummaryInterfacefunctionality is required, you can create these limited functionality, less-expensive-to-create objects.Just some ideas.