構造邏輯在服務合同

我有一個服務合同：構造邏輯在服務合同

[DataContract] 
public class Something 
{ 
    [DataMember] 
    public MyEnum SomeEnumMember {get;set;} 
}

一些我們的開發人員都在做這樣的事情：

public Something() 
{ 
    SomeEnumMember = MyEnum.SecondEnumValue; 
}

我認爲構造邏輯不屬於在我們的服務合同中，因爲如果您使用「添加服務引用...」並且正在使用由Visual Studio生成的代理類，那麼該代碼將不起作用。

在內部，我們使用Castle DynamicProxy，如here所示。但是，我寧願我們的開發人員避免在服務合同類中使用構造函數邏輯，以防因某種原因無法使用DynamicProxy。

所以：構造函數邏輯是否在這些類中佔有一席之地，或者作爲最佳實踐，我們應該將它們看作更多的DTO並在沒有行爲的情況下實現它們？

來源

2012-05-11 Dave Ziegler

我可能是錯的，但是當反序列化對象時，如果傳入的XML（或其他內容）沒有屬性值，那麼它不會修改它的原始值。（另一方面，我可能是錯的，並且將始終分配類型的默認值）如果我是正確的，那麼在構造函數中分配值可以設置默認值，如果沒有明確提供。除此之外，我沒有看到一個好的情況下它的頭頂。如果其目的是嚴格地在域之間傳遞信息，我認爲在課堂上不應該有邏輯/方法。 –

謝謝。這正是我的思路：「我認爲邏輯/方法不應該在課堂上，如果它的目的是嚴格地在域之間傳遞信息」 –

我們今天早上進行了一些測試，並且這些枚舉默認爲第一個成員 - - 0，正如所料 - 儘管我們已經在構造函數中將它初始化爲其他東西。 –

只有在首先創建對象才能通過服務進行傳輸時，它纔會產生影響。如果您希望您的SomeEnumMember的默認值是實例爲方便傳輸的時候不同，它可能是有意義的：

var mySomething = new Something(); 
mySomething.SomeEnumMember = MyEnum.SecondEnumValue; //this line may be omitted if it's set automatically by the constructor 
SendData(mySomething);

在接收端，它會使沒有區別的值（I思考，並從你的測試）是由發件人明確設置。另外，你的接收器會實例化/反序列化這些對象，這將是額外的/浪費的工作，但很可能這是一個微不足道的開銷。

通常，您的數據傳輸對象不應該包含任何邏輯。也許取決於你的應用程序體系結構，如果你在除了傳輸信息之外的許多地方使用這個對象，這可能是有道理的。雖然我會質疑這種架構：我喜歡將與客戶端 - 服務器通信有關的對象從應用程序架構的其餘部分抽象出來。這樣我就可以自由地對其進行更改（專門的序列化，體系結構更改等），而不會嚴重影響我的其他應用程序。

來源

2012-05-11 20:06:28

好點。我只將這些視爲DTO，根本不需要任何行爲。我相信有兩個原因讓我看到這一點，1）我們正在使用DynamicProxy，因此構造函數邏輯正在被打擊，2）它被看作是默認枚舉值的解決方法。我只是不想在六個月的時間內完成任務，並且有人在沒有使用DynamicProxy的情況下連接到我們的服務之一，並想知道爲什麼事情會表現得很奇怪。那麼，init代碼沒有被擊中！ –

@ JackT.Colton這就是我所想的。此外，添加到DataContract對象的任何邏輯都意味着可能需要測試或可能導致錯誤的邏輯。讓您的DataContract對象在服務中引發異常並不令人愉快。你的情況很微不足道，但不太可能引起任何問題。然而，開發人員可能會考慮向DataContract對象添加更多不重要的代碼（驗證，業務邏輯，日誌記錄等），這可能會導致未來出現令人頭疼的行爲或意外行爲。確切地說， –

。感謝您的討論。 –

我同意你的觀點，我不認爲構造函數邏輯屬於那裏，我從來沒有真正使用過構造函數邏輯的wcf。

來源

2012-05-11 19:55:32 Machinegon

構造邏輯在服務合同

回答

相關問題