ibatis域建模 [英] ibatis domain modelling

问题描述

我正在研究一个项目的域模型。我有一个名为user的类，它有一个名为UserType的类作为其中一个属性。我知道当我想要选择所有用户时，我将使用连接来接收所有相应的用户类型。如何做插入？我必须为userType编写一个处理程序吗？或者我可以做一些类似

  INSERT INTO users（... usertype_id ...）VALUES（...＃{usertype .usertype_id} ...）
  

请帮助;

$ b $我已经花了整整一天试图弄清楚这一点。我使用的是ibatis 3.0，我是ibatis的新手。

解决方案

Ibatis不是一个完整的ORM框架，所以它不知道对象关系。
所以是的，如果要直接使用与表中记录完全对应的域对象，则必须编写类似于您的 INSERT 的内容;也就是说，如果您在Ibatis中映射的User对象没有 getUsertypeId（）方法（返回与表列usertype_id相对应的值），而是 getUserType（）方法。

（当然你也可以写一个 getUsertypeId（） code>方法，内部调用 getUserType（）。getId（） ...但只是停在这里，不要假装也是一个 setUserTypeId（int id ），它内部尝试从Db等加载UsertypeId等等，这就需要麻烦，你会重新开发JPA / Hibernate。）

我不认为TypeHandler 是正确的方法，该功能更倾向于转换非平凡类型，而不是处理关系。 p>

另一种有效的方法是使用一层相对较低级别的POJO，每个表大致一个POJO，其属性直接映射到表列（例如， code> UserDb 对象w一个 userTypeId 属性，没有 getUserType（）方法，没有商务智能，依赖于上层或持久性知识） ，然后，还有一层更丰富的真实域对象，每一个都包含了这些笨POJO的（通常是小的）图形，并具有调用持久层（例如DAO）所需的智能，加载/保存图表（也许是懒惰的）。

这种方法的一个优点是实际的ibatis映射（SQL编码）的核心可以通过 Ibator - 它甚至可以从DB模式创建POJO的代码。

大量读取涉及许多表格（报告）的数据，您可以创建其他三维特殊POJO（它直接对应于SELECT列，也可能具有一些基本的智能来显示值 - 像ViewModel）。 ..或甚至HashMaps。

PS：您可能想要阅读关于 DDD （以及诸如实体，价值对象，视图，上下文富域对象与贫血域对象的概念 eg ）。 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.

解决方案

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 a getUserType() method.

(Of course you can also write a getUsertypeId() method which internally calls getUserType().getId()... but just stop here and don't pretend to make also a setUserTypeId(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 UserDb object with a userTypeId property and no getUserType() 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.

这篇关于ibatis域建模的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！