Posted by: Rickie Lee (www.cnblogs.com/rickie )
Date: Apr. 2005
CSLA是Component-based, Scalable, Logical Architecture的簡寫，CSLA .Net是Rockford Lhotka基于.Net設計的一套N-tier分布式架構。
如果對該架構感興趣，可以從下面的連結下載下傳CSLA .NET源程式，先設定CLSA.NETv1.5/cslacs10/www/DataPortalcs目錄的Web application（DataPortalcs）屬性，下一步在本地編譯調試：
1．建立你自己的key檔案：
sn -k mykey.snk
2．在VS.NET中打開CSLA .NET項目，并編輯CSLA.Server.DataPortal，CSLA.Server.ServicedDataPortal，CSLA.Resources等項目中的AssemblyInfo.cs檔案，使keyfile屬性指向你所建立的key檔案：
[assembly: AssemblyDelaySign(false)]
// TODO: update this to point to your key
[assembly: AssemblyKeyFile(@"c:/download/mykey.snk")]
[assembly: AssemblyKeyName("")]
3．修改DataPortal Web項目中web.config配置檔案，設定相應的資料庫連接配接：
<appSettings>
<add key="Authentication" value="CSLA" />
<!-- TODO: update connection strings as appropriate -->
<add key="DB:PTracker" value="data source=ineroth;initial catalog=PTracker;user id=ptracker;password=ptracker" />
<add key="DB:Security" value="data source=ineroth;initial catalog=Security;user id=ptracker;password=ptracker" />
<!--
<add key="DB:PTracker" value="data source=ineroth;initial catalog=PTracker;integrated security=SSPI" />
<add key="DB:Security" value="data source=ineroth;initial catalog=Security;integrated security=SSPI" />
-->
</appSettings>
在正式的Production環境中，一般需要為每一個application建立一個單獨的DataPortal Web項目。DB:PTracker 為application的資料庫連接配接資訊，DB:Security 則為用來進行安全驗證的資料庫連接配接資訊。
4．編譯CSLA .NET項目。
現在，應該編譯通過了。
References:1. Rickie, CSLA .Net學習資料, http://www.cnblogs.com/rickie/archive/2005/03/23/123862.html
2. Rockford Lhotka’s homepage, http://www.lhotka.net/Default.aspx
posted on 2005-04-11 13:13 Rickie 閱讀(47703) 評論(9) 編輯 收藏 收藏至365Key 所屬分類: F.CSLA .Net href="http://www.cnblogs.com/rickie/Services/Pingback.aspx" target="_blank" rel="external nofollow" rel="pingback"/>
評論
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-11 16:51 Teddy's Knowledge Base csla好像是完全通過reflection構造business對象和調用對象的方法呢~~
有點怕怕~~ 真懷疑它的性能呢！
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-11 23:41 Rickie To Teddy,
Rockford has written an article about what you concerned, where he thinks it's not a performance issue.
Justifying reflection in the DataPortal
http://www.lhotka.net/Articles.aspx?id=4320e7f2-dd14-4928-b552-4eb0cb82cd68
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-12 11:56 Teddy "perhaps your performance requirements can't be met by the current implementation" ---- 這是作者文章中最後的話，我還是感覺他過于樂觀了，像這類對象建構和方法調用，對一個對性能略有要求的應用來講都是完全可以避免的性能損失，for each使用的類型轉換，實際沒有用反射，而一般來講dataaccess中用反射來動态加載資料通路子產品則可以在加載後作為全局共享變量，不用每次都建立的。但，他的這個方式可是業務邏輯層啊，邏輯簡單相對于其它代碼比例小的話還好，否則對大多數邏輯複雜度是應用的主要複雜度的應用，性能影響肯定會很大了呢~~
當然對性能要求不高的應用又比如單機客戶機應用來講還是很合适的，可以極大簡化代碼~~
另一方面，我總是覺得凡是反射，必然可以構造一個與其完全等價的代碼生成方案以在必要時與反射放按切換，或者，開發原型時用反射，後期釋出前再改成代碼生成，可能比較好~~
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-12 14:33 Rickie "他的這個方式可是業務邏輯層啊，邏輯簡單相對于其它代碼比例小的話還好，否則對大多數邏輯複雜度是應用的主要複雜度的應用，性能影響肯定會很大了呢~~ "
＝＝＝
Sorry, 我沒有明白你的意思。Server端的DataPortal采用Reflection機制擷取BusinessClass類型，并建立相應的對象執行個體，然後通過Reflection調用業務方法，這與"邏輯複雜度"有什麼關系？
另外，作者Rockford是以實際的資料測試來驗證Refection對CLSA.NET性能影響的，實際測試比較應該是一種值得推薦的方式。
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-12 17:09 Teddy 作者的實測資料沒有給出真正的測試項目，我覺得很難說明問題。
邏輯層複雜度的問題是指，羅基層對象構造的頻率遠高于資料通路，之前一段時間在部落格園也有不少朋友測試反射的性能損失，如果通路達到一定的頻繁度的話對性能影響挺嚴重的，是以至少我不喜歡這樣用反射。
當然也要具體情況具體分析，最好對特定的項目做性能實測分析。
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-12 23:36 Rickie To Teddy,
不錯，如果有時間，我會自己測試一下CSLA .NET中Reflection對性能的影響如何。
# re: 編譯調試CSLA .NET Framework v1.5 2005-05-20 17:12 舞者 我也正在研究CSLA.NET,有時間聯系:MSN:[email protected]
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-11 16:51 Teddy's Knowledge Base csla好像是完全通過reflection構造business對象和調用對象的方法呢~~
有點怕怕~~ 真懷疑它的性能呢！
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-11 23:41 Rickie To Teddy,
Rockford has written an article about what you concerned, where he thinks it's not a performance issue.
Justifying reflection in the DataPortal
http://www.lhotka.net/Articles.aspx?id=4320e7f2-dd14-4928-b552-4eb0cb82cd68
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-12 11:56 Teddy "perhaps your performance requirements can't be met by the current implementation" ---- 這是作者文章中最後的話，我還是感覺他過于樂觀了，像這類對象建構和方法調用，對一個對性能略有要求的應用來講都是完全可以避免的性能損失，for each使用的類型轉換，實際沒有用反射，而一般來講dataaccess中用反射來動态加載資料通路子產品則可以在加載後作為全局共享變量，不用每次都建立的。但，他的這個方式可是業務邏輯層啊，邏輯簡單相對于其它代碼比例小的話還好，否則對大多數邏輯複雜度是應用的主要複雜度的應用，性能影響肯定會很大了呢~~
當然對性能要求不高的應用又比如單機客戶機應用來講還是很合适的，可以極大簡化代碼~~
另一方面，我總是覺得凡是反射，必然可以構造一個與其完全等價的代碼生成方案以在必要時與反射放按切換，或者，開發原型時用反射，後期釋出前再改成代碼生成，可能比較好~~
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-12 14:33 Rickie "他的這個方式可是業務邏輯層啊，邏輯簡單相對于其它代碼比例小的話還好，否則對大多數邏輯複雜度是應用的主要複雜度的應用，性能影響肯定會很大了呢~~ "
＝＝＝
Sorry, 我沒有明白你的意思。Server端的DataPortal采用Reflection機制擷取BusinessClass類型，并建立相應的對象執行個體，然後通過Reflection調用業務方法，這與"邏輯複雜度"有什麼關系？
另外，作者Rockford是以實際的資料測試來驗證Refection對CLSA.NET性能影響的，實際測試比較應該是一種值得推薦的方式。
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-12 17:09 Teddy 作者的實測資料沒有給出真正的測試項目，我覺得很難說明問題。
邏輯層複雜度的問題是指，羅基層對象構造的頻率遠高于資料通路，之前一段時間在部落格園也有不少朋友測試反射的性能損失，如果通路達到一定的頻繁度的話對性能影響挺嚴重的，是以至少我不喜歡這樣用反射。
當然也要具體情況具體分析，最好對特定的項目做性能實測分析。
# re: 編譯調試CSLA .NET Framework v1.5 2005-04-12 23:36 Rickie To Teddy,
不錯，如果有時間，我會自己測試一下CSLA .NET中Reflection對性能的影響如何。
# re: 編譯調試CSLA .NET Framework v1.5 2005-05-20 17:12 舞者 我也正在研究CSLA.NET,有時間聯系:MSN:[email protected]
![Xcode中建立Target的步驟[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)