同一类中的 OOP 值对象和实体
我正在将一个旧的程序 PHP 网站重构为一个美味的 OOP 应用程序,并添加少量的领域驱动设计以增加风味。
我不断地遇到需要可以具有实体或值对象子类的类的情况。
例如,一个 url 对象。那里有无数的网址,所以它们不可能都是真正的实体。但有些是非常特殊的网址,比如我的主页。那是一个实体。
另一个例子是“配置对象”。我希望某些配置具有身份,以便我可以创建“预设”并通过在线控制面板管理它们。对于那些,需要一个查找器/存储库来找到它们,并且需要 ORM 来管理它们的生命周期。但是,对于其他“非预设”(同一类层次结构的),我希望能够向它们加载已动态自定义且不需要保留的数据。
我设想了很多:
class factory {
reconstitute($rawdata) {
if (raw data has identity)
load up and return entity version of the class
else
load up and return anonymous/value object version of the class
这一切似乎有点奇怪。
是否有任何模式可以讨论处理此问题的最佳方法?
I am refactoring an old procedural PHP website into a tasty OOP application with a light sprinkling of Domain Driven Design for added flavour.
I keep stumbling upon cases where I have a need for classes that can have subclasses which are either entities or value objects.
An url object, for example. There are a zillion urls out there and so they all cannot really be entities. But some are very special urls, like my home page. That is an entity.
Another example is, say, a 'configuration object'. I'd like some configurations to have identities so i can create 'presets' and administer them via an online control panel. For those a finder/repository is needed to find them and ORM is needed to manage their lifetimes. But, for others 'not-presets' (of the same class hierarchy) I'd like to be able to load them up with data that has been customised on the fly and does not need to be persisted.
I am envisaging a lot of :
class factory {
reconstitute($rawdata) {
if (raw data has identity)
load up and return entity version of the class
else
load up and return anonymous/value object version of the class
It all seems a bit odd.
Is there any pattern out there that discusses the best way to handle this issue?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我不确定我完全理解你的场景,但是……这真的重要吗?
根据我使用 EF/ORM 的经验,(我能想到的)做你想做的事情的最好方法是让你的实体类决定是否根据定义的业务规则从数据库加载/持久化自身在课堂上。
不确定这是否真的对您有帮助或者是否适用。
I'm not sure I totally understand your scenerio but... does that really matter?
In my experience with EFs/ORMs the best way (that I can think of) to do what you are wanting to do is to let your entity class decide whether or not to load/persist itself from/to a database based on business rules defined in the class.
Not sure if that really helps you out or if it even applies.