Phải làm gì khi tên thuộc tính khớp với tên lớp

Question

Trong mã C# của chúng tôi, chúng tôi có một lớp được gọi là Dự án. lớp cơ sở BusinessObject của chúng tôi (đó là tất cả đối tượng kinh doanh kế thừa từ) định nghĩa một tài sản:

public Project Project { get; set; } 

Đây là bình thường không phải là một vấn đề miễn là chúng ta ở lại trong C# codebase. Tuy nhiên, các lớp đối tượng nghiệp vụ này được trưng ra trong các dịch vụ web qua dây. Một số ngôn ngữ tiêu thụ (chẳng hạn như ActionScript của Flex) không thể xử lý việc có một thuộc tính có cùng tên với lớp của nó.

Xung đột đặt tên này xảy ra khắp nơi trong mã của chúng tôi. Đôi khi thật dễ dàng để thay đổi tên của thuộc tính hoặc lớp học. Đôi khi nó thực sự khó khăn. Chúng tôi đã cướp bộ não của chúng tôi và không thể đưa ra một cách tiêu chuẩn tốt để xử lý điều này. Có thể đổi tên lớp Project thành ProjectType hoặc ProjectInfo, nhưng điều này là xấu và phá vỡ tất cả các mã hiện có của người tiêu dùng của chúng tôi. Chúng ta có thể để tên kiểu giống nhau và thay đổi tên của thuộc tính thành ProjectInfo, nhưng điều này gây ra cùng một vấn đề.

Có ai có bất kỳ hướng dẫn hoặc phương pháp hay nhất nào cho tình huống như vậy không?

EDIT:

Đối phó với một số những gợi ý đưa ra:

• Phương pháp không được tiếp xúc qua dây dẫn, vì vậy chúng tôi không thể sử dụng phương pháp này.
• Tôi thích quy ước đặt tên chuẩn hơn cũng tuân thủ các tiêu chuẩn đặt tên của riêng Microsoft.
• Hiển thị một hợp đồng khác cho Flex có thể là một tùy chọn. Tuy nhiên, chúng tôi đang sử dụng Weborb cho Flex interop. Weborb sử dụng sự phản chiếu để khớp chính xác với tên thuộc tính, thay vì sử dụng tuần tự hóa XML hoặc SOAP. Nếu bất cứ ai biết thêm về serialization tùy chỉnh với Weborb, đó sẽ là hữu ích.

EDIT # 2:

Để tham khảo, chúng tôi đã kết thúc đổi tên tài sản cho một cái gì đó như:

public Project ProjectInfo { get; set; } 

Answer 1

tôi sử dụng camelCase thay vì UpperCase, đối với tên của các thành viên (phương pháp và tài sản).

Điều này trái với quy ước đặt tên chuẩn, vì vậy tôi không thể gọi đó là "thực hành tốt nhất" (nhưng, đó là điều tôi thích).

Vì vậy, trong ví dụ của bạn tôi sẽ xác định:

Project project { get; set; } 

Answer 2

Làm thế nào về phương pháp cũ tốt? (GetProject/SetProject HOẶC cách thức .net thực hiện nó - Thread.CurrentThread)

Answer 3

Nghe có vẻ như bạn đã có một vấn đề khó hiểu nếu bạn đã có dịch vụ web trên mạng với tên có vấn đề. Nếu bạn không thể thay đổi bất kỳ thứ gì mà không làm hỏng khách hàng hiện tại và bạn không thể rời khỏi nó vì nó không bị ngắt Flex, ai đó đang bị bị hỏng.

Bạn có thể có khả năng hiển thị API song song ở một URL khác. Tôi đồng ý với đề xuất của Get/Set shahkalpesh của các phương pháp mà các tài sản sẽ có vấn đề.Điều tốt về điều này là bạn có thể đưa ra quyết định một lần và sau đó là nhất quán thay vì cần phải suy nghĩ về nó mỗi lần. Nó cũng có nghĩa là bạn có thể tự động hóa việc tạo API thứ hai dựa trên API đầu tiên.

Answer 4

WTF có tên của một biến trong một ngôn ngữ phải làm với một dịch vụ web?

Một người nào đó phải thực sự lười biếng trong việc ràng buộc XML của họ để biết chi tiết triển khai được hiển thị trên dây.

Toàn bộ điểm của WSDL/SOA là bạn có thông số kỹ thuật cho thông báo độc lập với việc triển khai. Nếu bạn tạo thông số kỹ thuật thư từ mã nguồn hoặc tạo nguồn từ các đặc tả mà không cho phép biến thể của các đối tượng được tạo, bạn sẽ kết thúc với các hệ thống được kết hợp chặt chẽ. Một triệu chứng của khớp nối chặt chẽ này là nhận được tên biến/thuộc tính không phải là định danh hợp pháp. Một dịch vụ (chứ không phải là RPC) không được kết hợp chặt chẽ. Bạn không cần phải thay đổi việc triển khai dịch vụ của mình để phục vụ cho việc triển khai dịch vụ - nếu bạn phải làm như vậy, một thứ gì đó trong ngăn xếp của bạn bị hỏng. Điều đó xảy ra với các biến/thuộc tính của thành viên cũng như các phương thức.

Answer 5

Mặc dù nó không thực sự giúp đỡ cho các ngôn ngữ bên ngoài có thể không gian tên bí danh (presumming Dự án lớp là trong một namespace khác biệt cho các lớp học với các dự án bất động sản), như vậy:

using ns = MyProject.Namespace; 

Sau đó, bạn chỉ cần làm:

var newProject = new ns.Project(); 

Answer 6

Tôi nghĩ giải pháp tốt nhất là refactor dự án của bạn để đổi tên đối tượng Project thành WnProject, ProjectBase hoặc một cái gì đó khác có liên quan đến chính xác dự án là gì.

Đó là API của bạn, bất kỳ ai tiêu thụ nó đều phải hiểu rằng có thể có những thay đổi đột phá được vận chuyển, đó là chi phí phụ thuộc vào các nguồn bên ngoài.

Answer 7

Tôi biết đây là câu hỏi cũ nhưng có thể giúp người khác.

Tại sao không cung cấp WSDL khác cho người tiêu dùng không hỗ trợ cùng tên và loại chống sao?
Đổi tên complexType trong WSDL

Từ những gì bạn (nên) có bây giờ (KHÔNG tên nguyên tố!):

<xs:element name="Project" type="Project"/> 

<xs:complexType name="Project"> 
    <xs:sequence> 
    <xs:element name="Title" type="xs:string"/> 
    <xs:element name="Description" type="xs:string"/> 
    </xs:sequence> 
</xs:complexType> 

Để:

<xs:element name="Project" type="ProjectType"/> 

<xs:complexType name="ProjectType"> 
    <xs:sequence> 
    <xs:element name="Title" type="xs:string"/> 
    <xs:element name="Description" type="xs:string"/> 
    </xs:sequence> 
</xs:complexType> 

Trong trường hợp này, SOAP -message sẽ vẫn chính xác như nhau, có nghĩa là bạn không phải biên dịch lại giải pháp của bạn cũng như không cung cấp dịch vụ khác.
Ngoài ra, những người tiêu dùng khác sẽ không phải thay đổi bất cứ điều gì.