locked
Usage of Astoria in ASP.Net Application? RRS feed

  • Question

  • This is a followup question to my previous question about Astoria and SL.
    Although Pablo was nice to offer a good solution, but I further thought about it and here is my new updated question:

    Is it possible or advisable to use Astoria service as the data provider to an ASP.Net application (so the ASP application would act as a client app) and at the same time the "Same" Astoria service be used for the future SL client app?

    My ultimate goal is to have a SL 2.0 App that uses Astoria service. But what if I start this app using ASP.Net for now and then later on switch the client side when SL is fully released.

    Does this make sense? If yes, are the bits available for ASP.Net to consume Astoria Service?

    Thank you in advance!

    [Edit] My inquiry about using ASP.Net with Astoria is not using Astoria with AJAX but simply with ASP.Net components.

    Thursday, December 20, 2007 10:58 PM

Answers


  • The scenario where an ASP.NET application consumes a *remote* Astoria service makes all sense and we consider it a very important scenario (e.g. an ASP.NET app that uses a 3rd party online service).

    On the other hand, consuming an Astoria service within the same process carries a lot of overhead with it. One of the cool things about the way Astoria is organized is that the data source is just a .NET class, so you can use that class directly inside the server instead of going through the HTTP interface in loopback. In the case where you use Astoria on top of a database using the Entity Framework, you get even more fidelity because both the HTTP interface to data and the Entity Framework interface are based on the same EDM schema, so you get the same concepts, names, etc.

    In fact, we consider that scenario a target scneario as well: you're writing an ASP.NET app, and some of your logic is on the server and some on the client. For the logic on the client you use Astoria to get/push data. For the logic on the server you just use the same Entity Framework model (or some other data source) directly. Both will have the same entity types/prop names/etc.


    Pablo Castro
    Technical Lead
    Microsoft Corporation
    http://blogs.msdn.com/pablo

    Sunday, December 23, 2007 1:45 AM
    Moderator

  • We're still sorting out the details of both schedules. Regardless of the details, we ARE building a client for Silverlight and we'll make it available as soon as both the Silverlight beta and the Astoria client are ready.

    Pablo Castro
    Technical Lead
    Microsoft Corporation
    http://blogs.msdn.com/pablo

    Monday, December 24, 2007 7:31 PM
    Moderator

All replies


  • The scenario where an ASP.NET application consumes a *remote* Astoria service makes all sense and we consider it a very important scenario (e.g. an ASP.NET app that uses a 3rd party online service).

    On the other hand, consuming an Astoria service within the same process carries a lot of overhead with it. One of the cool things about the way Astoria is organized is that the data source is just a .NET class, so you can use that class directly inside the server instead of going through the HTTP interface in loopback. In the case where you use Astoria on top of a database using the Entity Framework, you get even more fidelity because both the HTTP interface to data and the Entity Framework interface are based on the same EDM schema, so you get the same concepts, names, etc.

    In fact, we consider that scenario a target scneario as well: you're writing an ASP.NET app, and some of your logic is on the server and some on the client. For the logic on the client you use Astoria to get/push data. For the logic on the server you just use the same Entity Framework model (or some other data source) directly. Both will have the same entity types/prop names/etc.


    Pablo Castro
    Technical Lead
    Microsoft Corporation
    http://blogs.msdn.com/pablo

    Sunday, December 23, 2007 1:45 AM
    Moderator
  • The scenario where an ASP.NET application consumes a *remote* Astoria service makes all sense and we consider it a very important scenario (e.g. an ASP.NET app that uses a 3rd party online service).


    Hi Pablo;

    Thank you for detail answer. Yes, that above statement was my real question. I can see in the long run, Astoria becomes the central data junction for many of MSFT technologies, i.e. Silverlight, ASP.Net, WinForms, Smart Client and etc.

    Pablo, do you anticipate at the time of SL 2.0 beta release, we would also have the client version of Astoria for SL 2.0?
    Thanks and Happy Holidays!

    Sunday, December 23, 2007 2:37 AM

  • We're still sorting out the details of both schedules. Regardless of the details, we ARE building a client for Silverlight and we'll make it available as soon as both the Silverlight beta and the Astoria client are ready.

    Pablo Castro
    Technical Lead
    Microsoft Corporation
    http://blogs.msdn.com/pablo

    Monday, December 24, 2007 7:31 PM
    Moderator
  • we ARE building a client for Silverlight and we'll make it available as soon as both the Silverlight beta and the Astoria client are ready.

    Pablo, thank you for the FIRM answer. One without the other is like trying to eat [hot] soup without spoon
    Tuesday, December 25, 2007 3:42 PM