tag:blogger.com,1999:blog-4291069679343025964.post5078965262711688394..comments2024-02-01T11:23:21.363+08:00Comments on .NET Walker: 重要的事情先做Davidhttp://www.blogger.com/profile/14918558855624275059noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-4291069679343025964.post-46632395566202177412014-03-10T17:18:15.751+08:002014-03-10T17:18:15.751+08:00寫得很棒!能夠照這篇文章執行的人是少數,但還是要往這目標靠近寫得很棒!能夠照這篇文章執行的人是少數,但還是要往這目標靠近binboyhttps://www.blogger.com/profile/00649015115755827427noreply@blogger.comtag:blogger.com,1999:blog-4291069679343025964.post-19273748566336670772008-07-31T15:46:00.000+08:002008-07-31T15:46:00.000+08:00Hi:我寫了一個動態產生xaml的.cs,這隻.cs放在主要路徑(/)下沒有問題,但我如果開了一個c...Hi:<BR/>我寫了一個動態產生xaml的.cs,這隻.cs放在主要路徑(/)下沒有問題,但我如果開了一個controls的目錄將.cs放入然後重拉就會出現找不到.xaml了,看了source發現他將原來的XamlUrl="#..."改成了"controls/#..."應該是這個原因造成($create(Sys.Preview.UI.Xaml.Control, {"xamlSource":"../Controls/#InLineXaml_ctl00.....)<BR/>請問要如何更改才能避免這個問題,謝謝!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4291069679343025964.post-52226625886146236422008-07-27T23:47:00.000+08:002008-07-27T23:47:00.000+08:00感謝您的回應。黃忠成老師,最近一年出的兩本「極意之道」,有稍微介紹到這個「分頁」的大問題,但只是用 ...感謝您的回應。<BR/><BR/>黃忠成老師,最近一年出的兩本「極意之道」,有稍微介紹到這個「分頁」的大問題,<BR/>但只是用 sql server 2005 的 ROW_NUMBER() 特解,這兩本書,和他更久以前出的一本 ASP.NET 1.1 元件設計,也有很多不錯的主題,可惜在台灣都賣得不好。<BR/><BR/>很可怕的是,該「分頁」主題,在台灣任何繁中 ASP.NET 的書都沒再有人提到,造成了台灣現在線上,滿坑滿谷效能奇差、不斷大量「全撈又重撈資料表」的 GridView。Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4291069679343025964.post-40731431070312292082008-07-27T21:53:00.000+08:002008-07-27T21:53:00.000+08:00關於這個問題,我的看法是這樣,在ASP.NET開發的領域當中,有相當多的中高階領域尚未被觸及和討論到...關於這個問題,我的看法是這樣,在ASP.NET開發的領域當中,有相當多的中高階領域尚未被觸及和討論到,確實是相當可惜的,除了效能之外,安全性也是一個被忽略的問題,例如我幾乎沒有看到繁中的ASP.NET書籍討論到ASP.NET中使用到Windows驗證時的安全性問題,NTLM和kerberos與ASP.NET驗證的關係,或是分散式應用程式架構下ASP.NET所扮演的角色,又或是MemberShipProvider的機制,這些主題跟ObjectDataSource一樣,很容易在作者出版書籍的時候直接被忽略了,然而這是為什麼呢?<BR/><BR/>其實,也不是沒有書籍討論,然而看起來繁中書籍的市場餵納量似乎並不足以支撐中高階書籍的銷售,很多作者嘗試過,但是出來的狀況卻差強人意,久而久之作者很容易就慢慢失去原先的動力了。資訊書籍的作者寫出一本書的時間可能要比做一個專案更長(還不包括內容的醞釀與整理),然而獲利可能是專案的30%不到,我想這可能是大部分讀者無法理解的。<BR/><BR/>坦白說,這些主題確實很重要,但是依照目前的現況,可能在BLOG或是Seminar上呈現比較容易,在繁中書籍上呈現恐怕比較困難,不過簡中書籍和BLOG上確實資料相對較多,我自己也有開發團隊在深圳,對於兩岸之間軟件設計的發展演進,我也挺有感觸(如果以後有時間,或許再寫篇分享),這些問題我也曾與其他作者以及出版社編輯都有聊到,確實,我們都有責任,不過我想大概也只能量力而為了,台灣的出版市場很蓬勃,但是獲利可能比大家想的要相差很多,儘管我們對台灣有很大的期待,也希望能夠看到軟體產業在這邊能夠有更好的發展,只是市場的支撐力道還是相當的重要。<BR/><BR/>不過,隨著BLOG和internet的普遍,其實我發現很多業界軟體從業人員的BLOG內容也寫的相當不錯,我想這是一個很好的開始,畢竟只靠幾位作者,遠不及大家一起努力去耕耘,這是一個百花齊放的年代,我相信有好的內容的BLOG一定會爭取到大家的支持,我真的很建議developer,不妨從自己的BLOG開始,如果有好的心得,隨時把它整理出來,和大家一起分享...<BR/><BR/>當然,我自己也會和大伙一起努力...多抽一點時間寫寫文章...^^Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4291069679343025964.post-28765527382503168892008-07-27T20:59:00.000+08:002008-07-27T20:59:00.000+08:00先不提一堆新技術,奚江華先生,三年前寫的帖子 : 當 DataGrid 遇上一百萬筆資料,http:...先不提一堆新技術,<BR/>奚江華先生,三年前寫的帖子 : <BR/>當 DataGrid 遇上一百萬筆資料,<BR/>http://blog.sina.com.tw/dotnet/article.php?pbgid=4907&entryid=3921<BR/><BR/>小弟我認為這種撈資料的「分頁」觀念真的很重要,<BR/><BR/>到目前為止,<BR/>台灣還有滿坑滿谷的 asp.net 網站,<BR/>GridView,還是用 SqlDataSource,每次 user 按頁碼換頁時,或按 title 排序時,<BR/>都是「整個資料表」全部重撈,<BR/>若有一百萬筆資料,就一百萬筆全部重撈,<BR/><BR/>或已用了 ObjectDataSource 控件,<BR/>但一堆工程師,都不知有此嚴重後果,<BR/>尤其重要的是,在系統開發期間都感覺不出來,<BR/>導致系統上線幾個月後、資料量變多時<BR/>才發現分頁效能奇差無比,<BR/>然後一堆台灣客戶,每個人都說 asp.net 效能奇差,<BR/>於是乎,台灣一堆人,都不再愛用 asp.net。<BR/><BR/><BR/>但,目前台灣幾乎沒什麼繁中書、blog 文有講到這種現象,<BR/>只有 msdn 的黃忠成先生,幾個月前在<BR/>msdn 繁中官網,有寫一篇有範例的「GridView 進階應用」文,<BR/>但他處理「分頁」,還只是用 sql server 2005 的 Row_Number() 函數,綁死在單一牌子資料庫的專屬解法。<BR/><BR/>現在台灣滿坑滿谷、效能奇差的 GridView 分頁網站,<BR/>其他什麼 .net 3.x, .net 4.0 新技術都免談了。<BR/>一堆客戶都已直覺認定,asp.net 網站,<BR/>當資料量多時,效能奇差。<BR/><BR/>然後一堆客戶、業主、工程師,還以為 asp.net 效能很差,<BR/>sql server 資料庫 效能很差,<BR/>只是開發速度快而已。<BR/><BR/>反觀對岸的 博客園 blog 社群,<BR/>已有滿坑滿谷這方面的「分頁」技術文件,<BR/>自己寫 stored procedure,或用 .net class 處理分頁,<BR/>且不限於 sql server 2005 的專屬解決方案。<BR/><BR/>這方面台灣的出版、台灣微軟官方真的很失敗,<BR/>沒把這點超重要的一點,大力宣導。<BR/><BR/>like this:<BR/>http://www.codeproject.com/KB/aspnet/PagingLarge.aspx<BR/><BR/><BR/><BR/>到目前為止,<BR/>出的書,<BR/><BR/>除了黃忠成先生,有稍微提到外,<BR/>似乎還沒任何作家,<BR/>介紹到此超重要觀念。<BR/><BR/>希望能有人站出來,<BR/>幫忙告知此一「分頁」問題的嚴重性。Anonymousnoreply@blogger.com