如何通过 Web 服务使用自定义属性?

发布于 2024-09-06 01:44:25 字数 873 浏览 4 评论 0原文

我目前正在尝试向 Web 服务中的属性添加自定义“列名称”。这是我的班级。

public class OrderCost
{ 
    public int OrderNum { get; set; }
    public int OrderLine { get; set; }       
    public int OrderRel { get; set; }
    public DateTime OrderDate { get; set; }
    public string PartNum { get; set; }
    public string Description { get; set; }
    public decimal Qty { get; set; }
    public string SalesUM { get; set; }
    public decimal Cost { get; set; }
    public decimal Price { get; set; }
    public decimal Net { get; set; }
    public decimal Margin { get; set; }
    public string EntryPerson { get; set; }
    public string CustID { get; set; }
    public string Customer { get; set; }
}

基本上我有另一个类(在 Silverlight 方面),它循环遍历所有属性并为每个属性创建一个列。问题是,我想使用属性名称以外的不同名称。例如,我想显示“订单号”而不是订单号。我尝试过使用自定义属性,但这似乎不起作用。有没有办法可以使用属性通过 Web 服务为这些属性提供不同的名称?还有其他方法可以实现我想要做的事情吗?

I am currently trying to add a custom "column name" to a property in a web service. Here is my class.

public class OrderCost
{ 
    public int OrderNum { get; set; }
    public int OrderLine { get; set; }       
    public int OrderRel { get; set; }
    public DateTime OrderDate { get; set; }
    public string PartNum { get; set; }
    public string Description { get; set; }
    public decimal Qty { get; set; }
    public string SalesUM { get; set; }
    public decimal Cost { get; set; }
    public decimal Price { get; set; }
    public decimal Net { get; set; }
    public decimal Margin { get; set; }
    public string EntryPerson { get; set; }
    public string CustID { get; set; }
    public string Customer { get; set; }
}

Basically I have another class (on the Silverlight side) that loops through all the properties and creates a column for each property. Thing is, I want to use a different name other than the name of the property. For example, I would like to show "Order Number" instead of OrderNum. I have attempted to use custom attributes but that does not seem to work. Is there way I can provide a different name to these properties over a web service with a use of an attribute? Is there another way I can achieve what I am trying to do?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

为你拒绝所有暧昧 2024-09-13 01:44:25

不,属性或 .NET 特有的任何其他内容都不能在客户端和服务之间使用。请参阅“基础知识:Web 服务如何工作”了解原因不是。

No, neither attributes, nor anything else specific to .NET can be used between the client and the service. See "Basics: How Web Services Work" to learn why not.

绝不服输 2024-09-13 01:44:25

如果您正在寻找一种无需更新客户端应用程序即可控制服务器上的元数据的方法,那么我认为属性不是一个解决方案。一方面,属性是在编译时定义的,我认为您不应该在运行时操作它们,即使您有能力这样做。但另一个问题是,Web 服务实际上没有任何与 .Net 属性相对应的本机机制,因此没有内置方法来传达这些属性所代表的元数据。

如果您确实希望通过属性定义此元数据,那么您可以将 OrderCost 类放在单独的共享程序集中,以供 Web 服务和客户端应用程序使用。这里的缺点是,如果您想要更改在属性中定义的值,那么客户端应用程序在获得更新的 DLL 之前不会看到这些更改。

或者,如果您希望客户端应用程序完全不知道元数据的任何更改,那么我会考虑创建某种 Display 类,其中包含您想要的显示信息并作为结果的一部分返回。

例如,下面的代码显示了一个名为 MyResultObject 的类,其中包含一个“Display”对象和一个“Data”对象列表。显然,命名空间、类名和这些类的组织取决于您:

namespace MyApplication
{
    public class MyResultObject
    {
        public Display.OrderCost Display { get; set; }

        public IList<Data.OrderCost> Data { get; set; }
    }
}

namespace MyApplication.Display
{
    public class Column
    {
        public string HeaderText { get; set; }
        public bool Visible { get; set; }
    }

    public class OrderCost
    {
        public Column OrderNum { get; set; }
        public Column OrderLine { get; set; }
        public Column OrderRel { get; set; }
        public Column OrderDate { get; set; }
        public Column PartNum { get; set; }
        public Column Description { get; set; }
        public Column Qty { get; set; }
        public Column SalesUM { get; set; }
        public Column Cost { get; set; }
        public Column Price { get; set; }
        public Column Net { get; set; }
        public Column Margin { get; set; }
        public Column EntryPerson { get; set; }
        public Column CustID { get; set; }
        public Column Customer { get; set; }
    }
}

namespace MyApplication.Data
{
    public class OrderCost
    {
        public int OrderNum { get; set; }
        public int OrderLine { get; set; }
        public int OrderRel { get; set; }
        public DateTime OrderDate { get; set; }
        public string PartNum { get; set; }
        public string Description { get; set; }
        public decimal Qty { get; set; }
        public string SalesUM { get; set; }
        public decimal Cost { get; set; }
        public decimal Price { get; set; }
        public decimal Net { get; set; }
        public decimal Margin { get; set; }
        public string EntryPerson { get; set; }
        public string CustID { get; set; }
        public string Customer { get; set; }
    }
}

不过,我认为您应该问问自己,服务了解其数据如何显示是否有意义。相反,客户端使用它不理解的数据是否有意义,因此它需要元数据才能正确处理该数据?在某些情况下,这可能正是您想要做的,但我认为在一般情况下可能不是。无论如何,这取决于您的应用程序的正确方法是什么。

If what you're looking for is a way to control this meta-data on the server without having to update client applications, then I don't think attributes are a solution. For one thing, the attributes are defined at compile-time, and I don't think you should manipulate them at runtime even if you have the ability to do so. Another problem, though, is that web services don't really have any native mechanism that corresponds to .Net attributes, so there isn't a built-in way to communicate the meta-data that those attributes represent.

If you really want to have this meta-data defined through attributes, then you could put your OrderCost class in a separate shared assembly for both the web service and client applications to consume. The downside here is that if you want to change the values you defined in your attributes, then the client applications would not see those changes until they obtained the updated DLL.

Alternatively, if you want client applications to be totally ignorant of any changes to the meta-data, then I'd consider creating some kind of Display class that contains the display information that you want and gets returned as part of the result.

For example, the code below shows a class named MyResultObject, which contains a single "Display" object and a list of "Data" objects. Obviously, namespaces, class names, and organization of those classes is up to you:

namespace MyApplication
{
    public class MyResultObject
    {
        public Display.OrderCost Display { get; set; }

        public IList<Data.OrderCost> Data { get; set; }
    }
}

namespace MyApplication.Display
{
    public class Column
    {
        public string HeaderText { get; set; }
        public bool Visible { get; set; }
    }

    public class OrderCost
    {
        public Column OrderNum { get; set; }
        public Column OrderLine { get; set; }
        public Column OrderRel { get; set; }
        public Column OrderDate { get; set; }
        public Column PartNum { get; set; }
        public Column Description { get; set; }
        public Column Qty { get; set; }
        public Column SalesUM { get; set; }
        public Column Cost { get; set; }
        public Column Price { get; set; }
        public Column Net { get; set; }
        public Column Margin { get; set; }
        public Column EntryPerson { get; set; }
        public Column CustID { get; set; }
        public Column Customer { get; set; }
    }
}

namespace MyApplication.Data
{
    public class OrderCost
    {
        public int OrderNum { get; set; }
        public int OrderLine { get; set; }
        public int OrderRel { get; set; }
        public DateTime OrderDate { get; set; }
        public string PartNum { get; set; }
        public string Description { get; set; }
        public decimal Qty { get; set; }
        public string SalesUM { get; set; }
        public decimal Cost { get; set; }
        public decimal Price { get; set; }
        public decimal Net { get; set; }
        public decimal Margin { get; set; }
        public string EntryPerson { get; set; }
        public string CustID { get; set; }
        public string Customer { get; set; }
    }
}

I think you should ask yourself, though, if it makes sense for a service to have any knowledge about how its data will be displayed. Conversely, does it make sense for a client to be consuming data that it doesn't understand, such that it needs meta-data in order to properly handle that data? In some cases that might be exactly what you want to do, but probably not in the general case, I think. Anyway, it's up to you what the correct approach is for your application.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文