原本準備通過乙個基類用子類進行拓展的方式來規劃不同**上爬取的商品,資料庫實現上用hibernate的joined-subclass。父表儲存所有共同資訊,子表主鍵為父表主鍵,存不同特異資訊。
後來發現其實每個子表的多餘資料都是它在相關**的id和買的鏈結所屬電商,id可直接在原表中賦值,所屬電商實際上沒有投入使用,索性去掉子表,直接用category註明所屬電商,沒有相關子表查詢,減少了資料庫讀,同時也避免了不同電商的子類的dao,serivice的編寫,其中大多數都重複操作,還有一定的特異性,復用有一定麻煩度,所以直接更換實體物件,把更多精力投入後續工作。
xml**
<
>
<
class
name="com.buygroup.entity.goodsbase"
table="goods"
>
<
idname="id"
>
<
column
name="id"
>
column
>
<
generator
class="identity"
>
generator
>
id>
<
property
name="currentprice"
column="currentprice"
type="float"
>
property
>
<
property
name="updatetime"
column="updatetime"
type="date"
>
property
>
<
property
name="goodsaddress"
column="goodaddress"
type="string"
>
property
>
<
property
name="imgaddress"
column="imgaddress"
type="string"
>
property
>
<
property
name="name"
column="name"
type="string"
>
property
>
<
property
name="species"
column="species"
type="byte"
>
property
>
<
property
name="category"
column="category"
type="byte"
>
property
>
<
joined-subclass
name="com.buygroup.entity.goodshpsh"
table="goodshpsh"
>
<
keycolumn="id"
>
key>
<
property
name="origin"
column="origin"
type="string"
>
property
>
<
property
name="idhpsh"
column="idhpsh"
type="int"
>
property
>
joined-subclass
>
<
joined-subclass
name="com.buygroup.entity.goodssmzdm"
table="goodssmzdm"
>
<
keycolumn="id"
>
key>
<
property
name="origin"
column="origin"
type="string"
>
property
>
<
property
name="idsmzdm"
column="idsmzdm"
type="int"
>
property
>
<
property
name="collect"
column="collect"
type="short"
>
property
>
joined-subclass
>
class
>
>
原來查詢的時候,用的是 inner join
sql**
hibernate:
insert
into
goods
(currentprice, updatetime, goodaddress, imgaddress, name, species, category)
values
(?, ?, ?, ?, ?, ?, ?)
hibernate:
insert
into
goodssmzdm
(origin, idsmzdm, collect, id)
values
(?, ?, ?, ?)
插入的時候是
sql**
select
goodshpsh0_.id as id1_0_,
goodshpsh0_1_.currentprice as currentp2_0_,
goodshpsh0_1_.updatetime as updateti3_0_,
goodshpsh0_1_.goodaddress as goodaddr4_0_,
goodshpsh0_1_.imgaddress as imgaddre5_0_,
goodshpsh0_1_.name
as name6_0_,
goodshpsh0_1_.species as species7_0_,
goodshpsh0_1_.category as category8_0_,
goodshpsh0_.origin as origin2_1_,
goodshpsh0_.idhpsh as idhpsh3_1_
from
goodshpsh goodshpsh0_
inner
join
goods goodshpsh0_1_
on goodshpsh0_.id=goodshpsh0_1_.id
where
goodshpsh0_.id=?
更改以後直接減少了資料庫負擔,也減少了**工作量。
不過以後的專案中 這個joined-subclass 還是有價值的。
實體框架中的變更跟蹤
實體框架支援在上下文的生命週期內對載入的實體的自動更改跟蹤。dbchangetracker類為您提供了上下文跟蹤的當前實體的所有資訊。請注意,每個實體必須具有entitykey 主鍵 屬性才能被上下文跟蹤。實體框架不會在沒有entitykey屬性的概念模型中新增任何實體。以下 片段顯示了上下文類如何...
實體與值物件
實體 在時間上有連續性,並且有唯一標識可以來區分的物件。值物件 用來描述事物的,不區分誰是誰的,不可變的物件。判斷乙個物件是實體還是值物件,還要根據它在具體的業務領域中的實際意義來決定,比如 體育館裡的座位,當業務領域這樣規定,一張門票對應乙個特定的座位,即每個座位都應該嚴格區分誰是誰,觀眾在選擇座...
OOP實體物件優化
定義和使用不方便,很容易把引數寫錯 當物件的屬性變化時,方法的引數必須改變 引數的改變,造成物件介面不穩定,降低了可維護性 可擴充套件性和安全性,與物件導向設計原則相悖 不符合物件導向中 低耦合,高內聚 的要求 後台方法編寫依賴資料庫完成 前台 實現依賴後台 方法的完成,團隊中無法並行開發 為類的設...