ibatis 领域建模
我正在研究一个项目的域模型。我有一个名为 user 的类，其中有一个名为 UserType 的类作为属性之一。我知道当我想选择所有用户时，我将使用联接来选取所有相应的用户类型。我该如何做插入？我必须为 userType 编写处理程序吗？或者我可以做类似
INSERT INTO users(... usertype_id ...) VALUES(... #{usertype.usertype_id}...)
“请帮忙”的事情吗？
我花了一整天的时间试图弄清楚这一点。我正在使用 ibatis 3.0，而且我是 ibatis 的新手。
I am working on the domain model for a project. I have a class named user that has a class named UserType as one of the properties. I know when I want to select all users, I will use joins to pick up all corresponding usertypes. How do I do inserts? Do I have to write a handler for userType? Or can I do something like
INSERT INTO users(... usertype_id ...) VALUES(... #{usertype.usertype_id}...)
Please help;
I have spent the whole day trying to figure this out. I am using ibatis 3.0 and I am new to ibatis.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Ibatis 不是一个完整的 ORM 框架，因此它不了解对象关系。
所以，是的，如果您想直接使用与表中的记录不完全对应的域对象，则必须编写类似 INSERT 的内容；也就是说，如果您在 Ibatis 中映射的 User 对象没有
getUsertypeId()方法（返回与表列 usertype_id 对应的值），而是有getUserType()方法代码>方法。（当然，您也可以编写一个 getUsertypeId() 方法，该方法在内部调用 getUserType().getId()...但就停在这里，不要假装让还有一个
setUserTypeId(int id) ，它在内部尝试从数据库加载 UsertypeId 等，这会带来麻烦。）我不这样做 。认为 TypeHandler 是正确的方法，该功能更适合转换非平凡类型，而不是处理关系。
另一种有效的方法是拥有一层相对低级的哑 POJO，每个表大约一个，其属性直接映射到表列（例如，带有
的属性，没有UserDb对象） userTypeIdgetUserType()方法，也没有商业智能、对上层的依赖或持久性知识），然后，在此之上，一层更丰富的“真实”域对象，每个对象都包装了那些“哑”POJO 的（通常很小）图，并且具有调用持久层（例如 DAO）来加载/保存图（可能是惰性的）所需的智能。这种方法的一个优点是，实际 ibatis 映射的核心（SQL 编码）可以使用 相当自动地完成Ibator - 它甚至从数据库模式创建 POJO 的代码。
对于涉及许多表（报告）的大量数据读取，您可以创建其他简单的临时 POJO（直接对应于 SELECT 的列，并且可能具有一些基本的智能来显示值 - 类似于“ViewModel”） ...甚至是 HashMap。
PS：您可能想阅读DDD（以及“实体”、“值对象”等概念） “视图”、“上下文”、“丰富域对象”与“贫血域对象”eg< /a>）。 Ibatis 为您提供了很大的灵活性来学习和实现这一点。
Ibatis is not a full ORM framework, so it doesnt know about objects relationships.
So yes, you must write something like your INSERT if you want to work directly with domain objects that do not fully correspond to a record in your table; that is, if the User object you are mapping in Ibatis does not have a
getUsertypeId()method (that returns the value corresponding to the table column usertype_id ) but instead agetUserType()method.(Of course you can also write a
getUsertypeId()method which internally callsgetUserType().getId()... but just stop here and don't pretend to make also asetUserTypeId(int id) which internally tries to load the UsertypeId from the Db, etc, etc... that calls for trouble. You'll end reinventing JPA/Hibernate.)I don't think a TypeHandler is the right approach, that feature is more oriented to converting non-trivial types, not so much for handling relationships.
Another valid approach is to have a layer of relatively low-level-dumb POJOs, roughly one for each table, with properties that map directly to your table columns (say, a
UserDbobject with auserTypeIdproperty and nogetUserType()method, and no bussiness intelligence, dependencies on upper layers or persistence knowledge), and then, on top of that, a layer of richer "real" domain objects, each of which wraps a (usually small) graph of those "dumb" POJOs, and has the intelligence necessary for calling the persistence layer (eg DAO) to load/save the graph (perhaps lazily).One advantage of this approach is that the core of actual ibatis mappings (the SQL coding) can be done fairly automatically with Ibator - it even creates the code of the POJOs from the DB schema.
For massive reads of data which involves many tables (reports), you can create other trviial ad-hoc POJOs (which corresponds directly to the columns of your SELECT, and perhaps have some rudimentary intelligence to display values - something like a 'ViewModel') ... or even HashMaps.
PS: You might want to read about DDD (and concepts like "Entities", "Value objects", "Views", "contexts" "rich domain object" vs "anemic domain objects" eg). Ibatis gives you much flexibility to learn and implement along this lines.