JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Software Design » J2EE DP  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to topicthreaded modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 Business Logic 介面之設計
kasimchen





發文: 5
積分: 0
於 2005-03-23 15:44 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
有一個對我很矛盾的問題想跟大家討論
在應用 J2EE Design Pattern 來設計 business logic 介面, 針對從資料庫 select 資料, 考慮以下兩個 case :

1. 介面可傳部分 SQL 語法 (例: " WHERE userdept LIKE 'ADM%'")
pro : method 擴充性大, 變動之限制條件可以由前端控制
con : 不能使用 PreparedStatement 防止 SQL Injection

2. 介面單純, 前端提供參數值, 後端處理細節
pro : 前端介面簡單, 可以使用 PreparedStatement 防止 SQL Injection
con : 需求變動也許就要改介面參數

以上我絕得最好使用第二個方法. 不過是不是變成每個小細節的不同都要寫成一個method? 而且需求變動也許就要改介面參數, 在使用 Design Pattern 而言不就是變成不變, 要改多支class/bean (Delegate, Facade, 等)

各位的意見是如何呢?


reply to postreply to post
作者 Re:Business Logic 介面之設計 [Re:kasimchen]
try





發文: 128
積分: 6
於 2005-03-24 00:21 user profilesend a private message to usersend email to tryreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
hi,

要不就用EJB,要不就用Hibernate加HQL,真的要用SQL的話

用類似iBATIS SQLMap之類的工具將SQL抽出來放在設定檔中似乎可以也可解決您的問題.

ps.看不出這和Core J2EE Patterns有什麼關係?

-try


try edited on 2005-03-24 00:42
reply to postreply to post
個人網站 - http://cfliao.net/
作者 Re:Business Logic 介面之設計 [Re:try]
kasimchen





發文: 5
積分: 0
於 2005-03-24 09:07 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
嗯.. 我是用 EJB 架構阿
但是沒有用 Entity Bean
只做到 Session Bean 去連結 JDBC 取資料
本人是絕得套用了 J2EE Patterns 是否要優先考慮 method 擴充性還是獨立性

舉個例: 原本設計一個 method 取得所有員工資料, 後續有需求變更是要按照部門或職等限制
假如只挑 Delegate 和 Facade 層來看而已
Business Delegate --> getEmployee(), getEmployee(String deptID), getEmployee(String rank)
Session Facade --> getEmployee(), getEmployee(String deptID), getEmployee(String rank)
感覺會有無線新增 method 針對不同的條件
比較若只設計一個 method getEmployee(String sql)
或者這是本來就是 Design Pattern 的精神? 請指教


reply to postreply to post
作者 Re:Business Logic 介面之設計 [Re:kasimchen]
joeyli





發文: 105
積分: 5
於 2005-03-24 11:19 user profilesend a private message to usersend email to joeylireply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
若要使用EJB, 建議:
1. 商業邏輯請放到Session Bean中, 所謂的邏輯包含:
(1) 資料的取得與整理
(2) 邏輯運算(ex: 算薪水, 統計員工人數....)
(3) 資訊比對
2. JSP + Servlet用來作網頁展現與操作流程的重新導向.
3. 最重要的: 設計時的思考邏輯請由presentation layer移到EJB layer, 由EJB層所要提供的服務為出發點, 做好EJB後再向前端延伸, 設計Session Facade是對的, 但設計時就要考慮到未來, 它應提供的是比較廣泛的服務, 而非僅是滿足Servlet一時的需求.

不要只是把EJB當作撈資料的DAO來用, 而將邏輯放在Servlet中, 這樣就會遭遇到你的狀況: 需要不斷的更動method以符合以各種view來取資料的需求.
況且這樣一來邏輯的共用性會差很多, 若將邏輯直接寫在Servlet中, 則直接使用其他UI介面技術所作的AP都要模擬web browser與server溝通, 不但效能比較差, 且若想要撰寫其他種類的UI都變成要先處理http的問題, 不如直接使用EJB的方便.

使用EJB時也應當需要分層疊上來, 最外層的Facade是提供service級的對外窗口, 然後由Facade再向下延伸, 去叫用別的EJB或Java calss來進行整合運算或整理資料的動作.
經過這樣分層的處理, 對外的介面就會"稍微"比較穩定, 因為對外介面經過Facade整合過. Facade必須提供比較通用的介面出來, 避免取資料的變動延伸到外界, 所以Facade在作之前, 就需要考量比較詳細一點, 可以用Use Cases或是Service為單位來設計Facade.
你可以將EJB看作是可以遠端被操作並且共用的物件, 物件的interface是需要保持相對穩定, 但不可能完全不改變(BusinessDelegate可以吸收這一層變動), 若真的覺得動到原本的Facade EJB無法接受, 就建立新的Facade EJB來提供新的服務, 然後修改BusinessDelegate來協助叫用新的Facade就可以了.


joeyli edited on 2005-03-24 12:31
reply to postreply to post
跨平台是個夢!
作者 Re:Business Logic 介面之設計 [Re:kasimchen]
next





發文: 29
積分: 0
於 2005-08-25 21:29 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Maybe U could try

" Replace Implicit Language with Interpreter "
(refactoring to patterns)

http://www.industriallogic.com/xp/refactoring/implicitLanguageWithInterpreter.html


reply to postreply to post
作者 Re:Business Logic 介面之設計 [Re:kasimchen]
pollux0505





發文: 2
積分: 0
於 2005-12-30 10:21 user profilesend a private message to usersend email to pollux0505reply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
大家好,我是刚到这里来的,这也是第一篇回复。
刚来到这里就觉得这里很干净,是一个学习的好地方!也希望以后能和大家成为朋友。

business logic界面设计,我想business logic界面应该是粗粒度的。我们也可以说business login界面是一个服务门面(service facade)。在传统的j2ee架构中,推荐把表现层和业务逻辑层在物理上的划分,当然这对于需要进行rmi通讯的client端和确实需要分布式开发的app来说是一个好的选择。那我们应该在两层之间通过TO来传递信息和数据。但如果采用的是后ejb的架构,并且完全放弃ejb的话,我们就不需要TO,因为它使我们的代码迅速膨胀,同时这也是严重违反OO原则的。我们应该直接将BO作为层之间的数据传输对象。


reply to postreply to post


JMyth 不朽的传奇
» JWorld@TW »  Software Design » J2EE DP

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8