使用了iis
做為宿主，客戶端呼叫
wcf服務的是
web應用程式。今天這個小節主要以介紹
wcf中傳輸的配置為主，我們把上一節的內容稍做改動，以體現出
"endpoint"與"a
、b、c"
。 由於我在教程一裡沒有手寫任何配置的**，
client
與service
端的web.config
都是自動生成的，當我們新增服務引用時
,ide
自動將客戶端的配置檔案中
endpoint
與引用的服務的
endpoint
匹配了。如下**所示：
客戶端web.config：
服務端web.config
**： 1
<?xml version=
"1.0"
encoding=
"utf-8"
?>2
3 4
5"true"
targetframework=
"4.0"
/>6
7 8
9 10
11 12"true"
/>13
14"false"
/>
1516
1718
"true"
/>19
20 21"true"
/>22
23 24
由上面的兩個配置檔案我們發現，客戶端
system.servicemode
節點有我們剛才講的
endpoint
，而服務端為什麼沒有？這不是和我們剛才講的有違背嗎？好吧，我們承認
ide生成的
web.config
中endpoint
很隱晦。那麼我們看下面手工修改後
[把對看起來很複雜並且對當前的學習無用的配置節刪掉
]的配置檔案的**
(我將服務端和客戶端放在一塊了)：
修改配置檔案後我們執行下，發現
wcf服務依然執行成功！！這次的配置檔案夠明顯了吧，不論是在服務端還是在客戶端，
endpoint中的a
、b、c
都是完全一樣的。也就是終結點完全匹配！
那麼第一次的配置檔案為什麼能執行呢？答案是我們把
wcf寄宿在
iis上，而
iis預設監聽的就是
協議[b
確定了]
並且位址也是相對於
iis上的檔案位址
[a確定了
]，合同更不用說了，找到
user.svc
什麼都有了
[c確定了
]，所以在服務端就沒有必要顯示的寫出
system.servicemodel
，不信你試試，把服務端的配置檔案中
system.servicemodel
節刪除，程式一樣可以執行！伺服器端的
endpoint
確定了，客戶端的
endpoint
自然要和服務端去對應，所以
ide在生成客戶端的配置檔案裡
endpoint
寫的很詳細的，而服務端卻沒有
endpoint。
應用程式間通訊 URL Scheme
ios 的設計思路是原則上禁止不同的應用程式之間相互訪問彼此的資料。雖然對於像我這樣的桌面應用開發人員而言，不能訪問程式以外的資料是不能想象的。但是從安全角度來說不失為乙個有效的策略。不過凡事總有例外，所以賈伯斯還是為程式間通訊開放了幾個介面。ios 上的應用程式可以通過向其它應用程式傳送乙個url...
WCF應用程式的程式集劃分
wcf tips之二 wcf應用程式通常屬於分布式的soa方案。為了體現服務契約的特點，有必要在設計wcf應用程式時，注意程式集的劃分。原則上，我們需要將服務契約 資料契約 服務實現分為單獨的三個程式集，這樣可以在一定程度上解除服務契約與服務實現的耦合，也便於對資料契約物件的管理。更重要的是，wcf...
Linux 應用程式，程序間通訊彙總（IPC）
程序間通訊方式 1.通訊 管道 fifo，訊息佇列，共享記憶體，socket uds 管道一般用於有有親屬關係的程序間進行通訊。核心自動處理管道的同步問題。管道通訊資料為流模型，不能區分不同時間傳送的兩條訊息。可以定長傳送每條資料，或者定義訊息分隔符。fifo相對於管道，多了路徑名，任意程序都可訪問...