咱們的名字叫乘法雲。咱們在挑戰的問題是前端
從業務想法到軟件上線,速度如何提升10x?
在上一篇文章中,咱們寫了一個很簡單的從前端直接提交改動到後端的例子。在複雜業務下,顯然是不容許前端直接改數據庫的數據,畢竟瀏覽器不是受信的執行環境。業務規則仍是必需要在後端驗證的。這篇裏咱們來看一下對於表單提交這個場景,乘法雲是如何簡化開發的。sql
這個表單例子的運行時效果如上圖所示。數據庫
表明數據庫表的 Reservation.tssegmentfault
@sources.Mysql() export class Reservation extends Entity { public seatCount: number; public phoneNumber: string; }
建表 SQL,注意 phoneNumber 上有惟一性約束:後端
CREATE TABLE `Reservation` ( `id` int(11) NOT NULL AUTO_INCREMENT, `phoneNumber` varchar(255) NOT NULL UNIQUE, `seatCount` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=latin1;
而後就是表明這個表單的 FormDemo.xml瀏覽器
<Card title="餐廳座位預約" width="320px"> <Form> {{ message }} <Input :value="&phoneNumber" label="手機號" /> <InputNumber :value="&seatCount" label="座位數" /> <Button @onClick="onReserveClick">預約</Button> </Form> </Card>
驗證邏輯,以及先後端交互的代碼都在同一個文件裏 FormDemo.ts學習
@sources.Scene export class FormDemo extends RootSectionModel { @constraint.min(1) public seatCount: number; @constraint.required public phoneNumber: string; public message: string = ''; public onBegin() { this.reset(); } public onReserveClick() { if (constraint.validate(this)) { return; } this.saveReservation(); setTimeout(this.clearMessage.bind(this), 1000); } @command({ runAt: 'server' }) private saveReservation() { if (constraint.validate(this)) { return; } const reservation = this.scene.add(Reservation, this); try { this.scene.commit(); } catch (e) { const existingReservations = this.scene.query(Reservation, { phoneNumber: this.phoneNumber }); if (existingReservations.length > 0) { this.scene.unload(reservation); constraint.reportViolation(this, 'phoneNumber', { message: '同一個手機號只能有一個預約', }); return; } throw e; } this.reset(); this.message = '預約成功'; } private reset() { this.seatCount = 1; this.phoneNumber = ''; } private clearMessage() { this.message = ''; } }
乘法雲相比傳統技術有如下創新點ui
經過省去了先後端 RPC 交互的 Request/Response 結構體的定義,能夠減小數據拷貝來拷貝去的代碼,減小系統中的概念。你能夠把表單自己想像爲人和機器"RPC"交互的 Request/Response 結構體,因此只是在先後端交互的時候複用了同一個結構體定義而已。this
固然若是 this 自己並無綁定到界面,那麼這個結構體就是純粹服務於先後端RPC的接口定義的用途。也就是咱們徹底能夠定義一個 NewReservationProtocol 的對象,而後由這個對象來完成先後端的RPC。這樣就和傳統的定義後端API的作法沒有區別了。只是這裏給了額外一個選擇,就是不要這個額外創造出來的中間狀態,選擇和前端表單複用同一份狀態。如何選擇,固然是取決於context啦。spa
下一篇咱們會展現更復雜更能體現差別的一些例子,敬請關注。
咱們爲頂尖工程師提供了與之相配的技術發揮空間、無後顧之憂的寬鬆工做環境以及有競爭力的薪酬福利。同時也爲高潛質的行業新人提供充分的學習和成長機會。
這裏,沒有996,崇尚高效。
這裏,話語權不靠職級和任命,靠的是代碼的說服力。
這裏,不打雞血,咱們用理性和內驅力去征服各類挑戰。
這裏,也會有項目排期,但不怕delay,咱們有充足的時間,作到讓本身更滿意。
工做地點在北京西二旗,薪酬待碰見招聘連接:https://www.zhipin.com/job_de...