设计ant项目代码生成器 about tp-micro HOT 31 CLOSED

1. 关于template代码架构有一个疑问：template里面包含controller，model，sdk。既然是基于微服务的架构，我觉得没有必要在一个微服务里面再细分mvc了， controller model sdk完全可以独立为3个独立的微服务了，尤其是model，按照之前用php框架的用法，model一般用于操作DB的，如果是微服务，我想model应该独立为专门管理db 和 cache的微服务，其他微服务通过rpc来获取数据。
   至于微服务代码怎么写，就交给用户自己定吧，我们只生成服务、路由和rpc接口就可以了。

2. 目前template代码里面自带生成的hanlder
   handler.gen.go
   // Divide division
   func (m *Math) Divide(args *types.MathDivideArgs) (*types.MathDivideReply, *tp.Rerror) {
   return model.MathDivide(args)
   }
   如果这里添加逻辑代码，那就跟生成的代码耦合了

from tp-micro.

1. 这里的model是业务逻辑层

from tp-micro.

2. 你没有理解controller model sdk三个目录是什么作用。一个微服务必然会有router、handler及其sdk代码的

from tp-micro.

这里的model可能很多人会误解，我刚开始的时候也是认为是db操作，能否换个名字来让定义更明确？

from tp-micro.

你们理解的model太狭义了，谁告诉你model==db操作的？model是数据模型，换言之是业务逻辑

from tp-micro.

handler.gen.go中.gen后缀表示该文件是生成的。这个文件是不允许被改动的。其业务逻辑是在model包实现的

from tp-micro.

controller目录的作用就是控制，注册model层的业务逻辑到API接口的作用

from tp-micro.

model建议换个名字吧，很容易误解，尤其用过php框架的

from tp-micro.

可能是以前的项目，原来在写java的时候都把db放model里，所以看到model第一反映就是业务逻辑和db操作相关，但是我觉得和我这种认知model太狭隘的人有不少

from tp-micro.

你们可以提修改建议，我的意见已经体现在代码了，你让我换名了，我认为model最合适啊。

from tp-micro.

知道MVC的现状吗？最严重的问题就是大部分人被某些框架带偏了，认为model就只是db，然后大段大段的业务逻辑都写在了控制层。。。

from tp-micro.

控制层是衔接M与V的，用在我们这个场景，就是衔接业务逻辑与API操作的

from tp-micro.

我不相信你们在学数据建模的时候，老师告诉你，db就等于数据模型

from tp-micro.

哈哈，几乎已经是共识了，model==db。等会我贴一个目录命名供你参考

from tp-micro.

数据模型所描述的内容包括三个部分：数据结构、数据操作、数据约束。
1）数据结构:主要描述数据的类型、内容、性质以及数据间的联系等，是目标类型的集合。目标类型是数据库的组成成分，一般可分为两类：数据类型、数据类型之间的联系。数据类型如DBTG(数据库任务组)网状模型中的记录型、数据项，关系模型中的关系、域等。联系部分有DBTG网状模型中的系型等。数据结构是数据模型的基础，数据操作和约束都基本建立在数据结构上。不同的数据结构具有不同的操作和约束。
2）数据操作:数据模型中数据操作主要描述在相应的数据结构上的操作类型和操作方式。它是操作算符的集合，包括若干操作和推理规则，用以对目标类型的有效实例所组成的数据库进行操作。
3）数据约束：数据模型中的数据约束主要描述数据结构内数据间的语法、词义联系、他们之间的制约和依存关系，以及数据动态变化的规则，以保证数据的正确、有效和相容。它是完整性规则的集合，用以限定符合数据模型的数据库状态，以及状态的变化。约束条件可以按不同的原则划分为数据值的约束和数据间联系的约束；静态约束和动态约束；实体约束和实体间的参照约束等。

from tp-micro.

@letmefly 嗯，如果有让大部分人能接受，又没有认知偏差的，我会欣然接受的

from tp-micro.

logic这个名字我觉得大部分都能看懂

from tp-micro.

@qiaohongbo 这个词我赞同

from tp-micro.

@qiaohongbo logic很直白，易理解。db与逻辑都包含其中，对吧？

from tp-micro.

@henrylee2cn 还是看大家的意见吧, 如果觉得行就可以

from tp-micro.

@henrylee2cn 我这种完全摒弃了controller model的概念了，用户直接logic里撸就可以了
main.go
[types]目录 --- 定义类型，自定义 + 生成类型
[route]目录 --- 路由，全自动生成
[handlers]目录 --- 对外服务API，全自动生成
[logic]目录 --- 全用户自己写的代码，只是一个目录不是一个package
[services]目录 --- service pool 相关的代码
[tests]目录 --- 测试这个服务的各种用例

from tp-micro.

services没必要，这部分在ant内部了

tests一般都在当前目录，因为如果跨包后就没法调用非导出变量了。

router和handler里面的代码太少，是否考虑合并？

from tp-micro.

@henrylee2cn 我在设计自动生成的配置文件的格式，遇到一个问题。
用swagger来设计api，用yaml来描述，太啰嗦了
比如

/pet/findByStatus:
get:
tags:
- "pet"
summary: "Finds Pets by status"
description: "Multiple status values can be provided with comma separated strings"
operationId: "findPetsByStatus"
produces:
- "application/xml"
- "application/json"
parameters:
- name: "status"
in: "query"
description: "Status values that need to be considered for filter"
required: true
type: "array"
items:
type: "string"
enum:
- "available"
- "pending"
- "sold"
default: "available"
collectionFormat: "multi"
responses:
200:
description: "successful operation"
schema:
type: "array"
items:
$ref: "#/definitions/Pet"
400:
description: "Invalid status value"
security:
- petstore_auth:
- "write:pets"
- "read:pets"

比如这样的描述，真正开发起来，api是非常不稳定的，随时都在修改，新增，删除，如果用这个来描述简直是噩梦。

Tars框架的API描述文件是这样的，类似java，看起来api是很清爽的，也比较容易修改，新增。所以我个人更倾向于这种描述，这种描述如果需要也是可以转成支持swagger格式的，如果这样的话，服务的api描述直接用go来描述，要么是参考protobuf 3 的 rpc描述。
附：

module TinyGame
{
//公共返回码参见公共定义如下在TinyGameCommDef中己定义:
//const int SS_RET_DATA_NOTEXIST = 1; //数据不存在
//const int SS_RET_SUCC = 0; //成功
//onst int SS_RET_SYSERR = -1; //系统错误
//const int SS_RET_ERRINTERFACE = -2; //接口已经不再支持
//const int SS_RET_ERROPT = -3; //错误的操作类型
//const int SS_RET_ERRPARAM = -4; //错误的输入参数

const int SS_RET_PAYCENTER_SHANXIPOINTS_NOTENOUGH     =  101;   
const int SS_RET_PAYCENTER_SHANXIPOINTS_ACCPWDERR     =  102;    

const int SS_RET_PAYCENTER_SINASHOWBI_NOTENOUGH             =  201;    
const int SS_RET_PAYCENTER_SINASHOWBI_CANNOTTOSHOWBINOW     =  202;    
const int CLIENT_TYPE_ANDROID = 1;
const int CLIENT_TYPE_IOS = 2;
interface SmsCode
{

	/*
		功能: 发送验证码短信
		@para: keyData key信息
	*/
	int sendSmsVerifyCode(string sAcc, long llRoleID, string sSendMobile, int iSendCode, int iCodeTimeOutMinit);
	int sendSmsVerifyCodeUni(string sSmsTemplateID, string sAcc, long llRoleID, string sSendMobile, int iSendCode, int iCodeTimeOutMinit);

}
struct TAppstoreVerifyPayInPara
{
0 require string sAccount; //帐号
1 require long llRoleID; //唯一出生ID
2 require string sPayCode; //支付代码
3 require string sPrice; //RMB单位元,订单对应的金额
4 require string sOssChannel; //运营渠道
5 require string sInnerOrderNumber; //对应的内部订单ID
6 require int iInnerGoodsID; //对应的内部商品ID
7 require string sPrivateStr; //内部鉴权串
8 require string sReceiptData; //内部鉴权串
9 optional string sAppID; //对应的APPID
};
struct TAppstoreVerifyPayOutPara
{
0 require string sOutOrderNumber; //对应的外部流水号,当确认为正常支付时
};

from tp-micro.

那就选择接近go风格的吧

from tp-micro.

@henrylee2cn router和handler 合并到handler里就好了，router我觉得应该是handlers的一部分，一般rpc框架好像没有路由的概念的，路由一般存在gate service里面比较多吧

from tp-micro.

嗯，放handler可以

from tp-micro.

@letmefly 更新后的项目结构：

├── README.md
├── main.go
├── api
│   ├── handlers.gen.go
│   ├── handlers.go
│   ├── router.gen.go
│   └── router.go
├── logic
│   └── math.go
├── sdk
│   ├── rpc.gen.go
│   ├── rpc.gen_test.go
│   ├── rpc.go
│   └── rpc_test.go
└── types
    ├── types.gen.go
    └── types.go

已在示例中更新：

https://github.com/henrylee2cn/ant/tree/master/samples/template

from tp-micro.

@henrylee2cn
初稿， typescrpit风格，我还会多弄几个风格，选一个最顺眼的风格。实现思路，正则表达式词法分析，递归下降语法分析

---service.proto---

// key words: type, api, string, int, long, list, map

// service name
ant := "mail"

// listen address
listen := "0.0.0.0:9090"

// heart beat
heartbeat := true

type User {
userId : string
nickname : string
}

// rpc api args
type RpcArgs {
a : int
b : int
c : string
userIdList : list
}

type RpcReply {
d : int
userList : list
userMap : map<string, User>
}

api {
getUserList (args : RpcArgs) -> RpcReply
getUserList2 (args : RpcArgs, args2 : RpcArgs) -> RpcReply
}

from tp-micro.

@letmefly 不错，看起来很清爽呀

from tp-micro.

@letmefly 只能有一个args参数：getUserList2 (args : RpcArgs, args2 : RpcArgs) -> RpcReply

handler的模板如下：

// - PullController Model Demo:

 type Aaa struct {
     tp.PullCtx
 }
 // XxZz register the route: /aaa/xx_zz
 func (x *Aaa) XxZz(args *<T>) (<T>, *tp.Rerror) {
     ...
     return r, nil
 }
 // YyZz register the route: /aaa/yy_zz
 func (x *Aaa) YyZz(args *<T>) (<T>, *tp.Rerror) {
     ...
     return r, nil
 }

// - PushController Model Demo:

 type Bbb struct {
     tp.PushCtx
 }
 // XxZz register the route: /bbb/yy_zz
 func (b *Bbb) XxZz(args *<T>) *tp.Rerror {
     ...
     return r, nil
 }
 // YyZz register the route: /bbb/yy_zz
 func (b *Bbb) YyZz(args *<T>) *tp.Rerror {
     ...
     return r, nil
 }

// - UnknownPullHandler Type Demo:

 func XxxUnknownPull (ctx tp.UnknownPullCtx) (interface{}, *tp.Rerror) {
     ...
     return r, nil
 }

// - UnknownPushHandler Type Demo:

 func XxxUnknownPush(ctx tp.UnknownPushCtx) *tp.Rerror {
     ...
     return nil
 }

from tp-micro.

现在进度怎么样了？

from tp-micro.