我正在研究项目的域模型。我有一个名为user的类，它有一个名为UserType的类作为其中一个属性。我知道当我想要选择所有用户时，我将使用连接来获取所有相应的usertypes。我该如何插入？我是否必须为userType编写处理程序？或者我可以做类似
的事情INSERT INTO users(... usertype_id ...) VALUES(... #{usertype.usertype_id}...)
请帮助;
我花了一整天时间试图解决这个问题。我使用的是ibatis 3.0，我是ibatis的新手。
答案 0 :(得分：3)
Ibatis不是一个完整的ORM框架，因此它不了解对象关系。
所以是的，如果你想直接使用与你表中的记录不完全对应的域对象，你必须写一些像你的 INSERT ;也就是说，如果您在Ibatis中映射的User对象没有getUsertypeId()方法（返回对应于表列usertype_id的值），而是getUserType()方法。
（当然你也可以编写一个getUsertypeId()方法，在内部调用getUserType().getId() ...但只是停在这里，不要假装也是setUserTypeId(int id）在内部尝试从Db等等加载UsertypeId ...这需要麻烦。你将重新发明JPA / Hibernate。）
我不认为 TypeHandler 是正确的方法，该功能更倾向于转换非平凡类型，而不是处理关系。
另一种有效的方法是使用一层相对低级别的哑POJO（每个表大约一个），其属性直接映射到表列（例如，UserDb对象{{1属性和没有userTypeId方法，没有业务智能，依赖于上层或持久性知识），然后，最重要的是，一层更丰富的“真实”域对象，每个对象都包含一个（通常很小的那些“哑”POJO的图形，并且具有调用持久层（例如DAO）来加载/保存图形所需的智能（可能是懒惰的）。
这种方法的一个优点是实际的ibatis映射（SQL编码）的核心可以使用Ibator相当自动地完成 - 它甚至可以从数据库模式创建POJO的代码。
对于涉及许多表（报告）的大量数据读取，您可以创建其他特殊的临时POJO（它直接对应于SELECT的列，并且可能具有显示值的一些基本智能 - 类似于'' ViewModel'）......甚至是HashMaps。
PS：你可能想要阅读DDD（以及“实体”，“价值对象”，“观点”，“上下文”，“富域名对象”与“贫血域对象”等概念{{3 }}）。 Ibatis为您提供了很多学习和实施的灵活性。