locked
Duplicated class in Silverlight project RRS feed

  • Question

  •  Hello All,


    I created one sample for consuming ADO.NET Data Service (Astoria) from Silverlight on the day after Astoria for Silverlight released.


    One thing that I noticed when I was creating that sample is that we have to create the custom class that has same name and same fields as the table in silverlight. For example, we have the table called Customers from database. We create a Data Model for Customers table in ASP.NET web application. then, if we want to use it in Silverlight application, we have to create another class with same name in Silverlight project again. This is duplicated things that I dont want to do. but it's like by-design issue.


    Do you guys think that Microsoft will do something about it? or Did I miss something in my steps?

     

    Saturday, January 26, 2008 7:15 PM

Answers

  • Hi Michael,

     

    In general, Astoria requires you to have knowledge of the service contract on the client and server (this is analogous to sharing interfaces in traditional WCF SOAP services).  Now, that said, we are doing a number of things to make this easier to deal with from a developer perspective...

     

    1) we provide a command line tool currently called "webdatagen.exe", but will be renamed in the next rev to something more inline with existing webservice tools.  This tool enables you to point it at a given Astoria data service and have it automatically create the client side types for you.  We are looking at integrating this tools in Visual Studio, but we'll see how far we get for the first rev.

     

    2) we are working on a model that will allow a loose coupling between client side types and server side types.  Expect to see more data on this approach in the coming rev and on our team blog, but the current drop provides a "ResolveName" and "ResolveType" property that enables you to have control over which client side type the library uses during serialization/deserialization

     

     

    Tuesday, January 29, 2008 4:32 AM

All replies

  • Hi Michael,

     

    In general, Astoria requires you to have knowledge of the service contract on the client and server (this is analogous to sharing interfaces in traditional WCF SOAP services).  Now, that said, we are doing a number of things to make this easier to deal with from a developer perspective...

     

    1) we provide a command line tool currently called "webdatagen.exe", but will be renamed in the next rev to something more inline with existing webservice tools.  This tool enables you to point it at a given Astoria data service and have it automatically create the client side types for you.  We are looking at integrating this tools in Visual Studio, but we'll see how far we get for the first rev.

     

    2) we are working on a model that will allow a loose coupling between client side types and server side types.  Expect to see more data on this approach in the coming rev and on our team blog, but the current drop provides a "ResolveName" and "ResolveType" property that enables you to have control over which client side type the library uses during serialization/deserialization

     

     

    Tuesday, January 29, 2008 4:32 AM
  • Thanks a lot for your reply.Mike. I also got the comment from Bryant.

    Tuesday, January 29, 2008 11:36 AM