有没有“太抽象”之类的事情？
我想知道我是否试图以 RAD 的名义抽象太多。
这里有一个例子 - 假设我有一个数据库表，其中有 3 个模型（主模型、映射器模型和数据库模型）。其中每一个都扩展了一个抽象模型、映射器和数据库表模型。
这个设置效果非常好。大部分操作实际上都在抽象模型中。但是，现在我想要更加抽象。我要走远吗？
我已经抽象了基本的 CRUD 操作，现在我正在考虑抽象更高级的操作。
一个例子是获取一些相关模型。目前我会这样做：
$modelOne->modelTwo();其中 modelTwo 是明确定义的。
我的想法是使用像injectModel('modelTwo') 这样的抽象方法或魔术方法。
我总是可以建立相关规则来确保我的模型保持完整性......但这是否太过分了？
感谢任何建议。
我不在乎我的某些代码有多么不连贯；我可以在这些部分写出清晰的文档和注释。
I am wondering if I am trying to abstract too much here in the name of RAD.
An example here - let's say I have a database table which has 3 models (the main model, the mapper model and the database model). Each of those extend an abstract model,mapper and db table model.
This setup works very nicely. The bulk of operations are actually in the abstract models. But, now I am wanting to abstract even more. Am I going to far?
I have already abstracted basic CRUD operations, now I am thinking about abstracting the more advanced ones.
An example of that would be fetching a few related models. Currently I would do this:
$modelOne->modelTwo(); where modelTwo is explicitly defined.
My idea was to then use either an abstract method like injectModel('modelTwo') or a magic method.
I can always build in the relevant rules to ensure my models maintain integrity...but is this too far?
Appreciate any advice.
I don't care how incoherent some of my code is; I can write clear documentation and comments in those parts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这正是我在开发当前应用程序时所采用的方法。现在，我在 Zend_Db_Table 和 Zend_Db_Table_Row 的顶部有一大堆抽象方法和魔术方法，用于获取和持久化模型的关系。
尽管一开始感觉还不错，但支持和引入新的抽象方法变得越来越复杂，更不用说团队其他成员在处理此代码时面临的困难（无论它的文档记录得多么好）。
这种方法感觉很像编写我自己的 ORM，这绝对不是我的计划。我现在最坚定的信念是我应该从一开始就采用教义。
That's precisely the approach I've taken in developing my current application. And now I have a whole bunch of abstract methods and magic methods for fetching and persisting model's relationships sitting on the top of Zend_Db_Table and Zend_Db_Table_Row.
Though it felt quite alright in the beginning, it's becoming more and more complicated to support and introduce even new abstract methods, not mentioning hardships other members of the team are facing when dealing with this code (no matter how well documented it is).
This approach feels pretty much like writing my own ORM, which I definitely didn't plan for. My strongest belief now is that I should've adopted Doctrine from the very beginning.
爱因斯坦不是说过“一切都应该尽可能简单，但不能简单一点”？
我简单的头脑对此的解释是，仅根据需要进行抽象。如果您比较流行的框架，您认为哪些框架过于抽象，以至于无法将您的注意力从正在做的事情上转移开？我认为 ASP.NET 和 Java 比 PHP 或 Node.js 更倾向于这样做。另外，如果将 XML 与 JSON 进行比较，可能会更明显地看出，过多的抽象会导致更重的负载和更重的智力负担。我不认为成为一名抽象学者比实践更有价值。
吻
Didn't Einstein say "Everything should be made as simple as possible, but not one bit simpler."?
How my simple mind interprets that is to only abstract as far as you need to. If you compare popular frameworks, which ones do you think abstract too far as to focus your attention away from what you are doing? I would argue ASP.NET and Java tend to do this much more so than PHP or node.js. Also, if you compare XML with JSON this is probably more obvious that too much abstraction leads to a heavier payload and a heavier intellectual weight. I don't see the value of being a scholar of abstraction over doing.
KISS