……在我最后阶段的创业公司中，我开始将所有的业务逻辑内容转移到我们的graphql服务器，并将其视为客户端团队的一部分。（我们有ios/android/web作为独立的完整应用，开发人员团队非常小）。业务逻辑才是真正的难题。让一个人来承担并用typescript（抱歉各位）在GQL/apollo服务器上实现，所有客户端都可以轻松地使用它。向客户端发送视图模型而不是数据模型。等等。这极大地减少了客户端的复杂性。
源讨论适用于Android的Swift SDK原帖 280 条评论 · 导入时统计> 每个跨平台框架最重要的问题是，UI会发生什么？ 我礼貌地不同意。我从跨平台框架中想要的第一个功能是它能让我编写原生UI。这就是我喜欢KMP的原因：我可以 just share a framework with an iOS app built with SwiftUI。 在很多情况下，共享业务逻辑非常有意义，并且一直如此（如C/C++/Rust/Go库等）。根据我的经验，在复杂的应用中共享UI总会变成一个“写一次 - 到处调试”的噩梦。 KMP（我希望Swift for Android也能如此）带来的可能性是，可以共享一个Kotlin（或Swift）库，而不是用C/C++/Rust/Go来共享代码。这样，Android/iOS团队可以继续使用Android/Swift，而无需引入第三种语言来共享逻辑。
完整原文把你的经验，加入这段讨论。
所以你的结论是业务逻辑应该在服务器上处理。这不是一直如此吗？
完整原文我想我不太明白你关于在客户端放置业务逻辑的意思。它只能在客户端吗？如果这样的话，显然你必须在服务器上复制它来检查客户端发送的结果是否正确，对吧？更不用说避免线程竞争和重复插入，以及在你允许客户端验证某事之前服务器上可能已经过时的其他问题了？即使你的代码不是面向公众的，服务器仍然需要检查所有内容。作为单独开发的人来说，我觉得把业务逻辑放在客户端上是疯狂的，除非客户端和服务器确实共享相同的typescript代码库来进行交叉检查操作，即使如此，服务器也需要相同的代码加上额外的保护措施。我很难理解为什么有人会从零开始构建一个主要业务逻辑在客户端的平台，如果服务器不是用同一种语言编写的的话…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。