这是一个建筑设计问题。
我有一个名为X的mySQL表。 我从一个有角度的2+前端对它进行了CRUD操作。
为了解决问题，我创建了一个我碰巧称之为create-new的组件。这个人现在在/create-new路线上运行。
但是，正如我开发的那样，这个创建新组件（带有.ts，.html和.css的朋友）已经变得非常通用，能够处理，而不仅仅是创建新的（因此插入）情况，还有更新。
此更新不仅可以在创建新操作之后正常工作（使用新插入的ID）以允许立即更新新创建的记录，还可以使用加载另一条记录的数据来提供它的更新表格。
所以，这个/创建新路线现在已经能够处理基于参数的请求，例如/ create-new /？action = edit＆amp; rec_id = 10
我喜欢这样一个事实：最初的创建新代码库非常容易升级到这个功能。现在插入，更新操作已经完成，我们不禁想到，为什么我不添加DELETE，LIST-VIEW和DETAIL-VIEW功能并完成它。考虑到建筑设计问题需要挑选经验丰富的大脑。
这种方法的专家，我有一个组件，它映射到一个单独的文件夹，一个.ts，.html，.css和服务器端.php页面，完善到使用该表X.这使得复制此功能非常容易，以获得另一个准备好处理表Y上的所有CRUD需求的集合，而对克隆基础的调整非常少。
我知道常见的模式是有一个用于create-new的组件，一个用于视图记录，一个用于view-list on和on。
我的问题如下：在所有情况下，这种全能（我刚才描述的）的方法是否是绝对的NO-NO-APPROACH？
或者，我们可以说嘿，这不是一件大事，事实上，根据情况，它可能是推荐的方法吗？
如果可以调整这种整合方法，我只需使用manage-X更改名称create-new并完成它。然后下一个人将被命名为manage-y，依此类推。我确实意识到，通过这种方法，HTML部分可能会对这种全能方式更加敏感。在这种情况下，我将不得不处理更长的.HTML文件（它不仅会托管与表X对话的add-edit-form，还会显示表X中记录的视图列表和视图详细信息。但那是我可以忍受的限制。
再次回到问题..
这种方法是否永远不会被吸收？ 或者有些情况下它保证它应该是要走的路？
如果构建这样的组件是可以的，那么决定采用这种整合方法的主要标准是什么？
答案 0 :(得分：0)
实际上有风格指南说不应该这样做，但恰恰相反。组件应尽可能小，并遵循单一责任原则。
来自docs：
将单一责任原则（SRP）应用于所有组件， 服务和其他符号。这有助于使应用程序更清洁，更容易 阅读和维护，更可测试。
REF：https://angular.io/guide/styleguide#single-responsibility