WCF Ria Services

I am about to write my own DomainService DAL for WCF Ria Services. This will provide a seemless code generation from LightSpeed to Ria Services. Should I attempt this (you guys know the internal mapping of LightSpeed Far Batter than I)? Or are you guys coming out with this very soon and I should not waste my time?

I would be converting the LinqToSQL DomainService to work with LightSpeed

http://code.msdn.microsoft.com/RiaServices/Release/ProjectReleases.aspx?ReleaseId=2660

We're not working on a RIA Services layer at the moment, so it's definitely not a waste of time.

That said, it's something we'd certainly like to have available as part of the product or via Community Code, so there may be scope for collaboration if you'd be open to this.

Is there any metadata info about the entities exposed by the LightSpeed libraries?

Metadata like Associations, PrimaryKey, etc?

Runtime metadata can be a bit tricky to untangle using the public API.  If you're a source code customer, check out the Web.DynamicData project and, for associations, in particular the LightSpeedColumnProvider and LightSpeedAssociationProvider classes.  In fact the Dynamic Data code in general is a pretty good starting point for working with metadata as it includes a general albeit simple metadata extractor and DataAnnotations support.  (I'd also suggest checking out the super-secret DataServices\DataServiceUnitOfWork which provides insert, update and delete support for ADO.NET Data Services.)

If you're not a source code customer, drop me a line (ivan @ the obvious domain name) and I'm sure we can arrange to provide the source code for these components.

We do have an internal API (the TypeModel family) that is the "master" source of info for the metadata, but we don't feel ready to make that public at this point.  If you think it's going to be worth getting down to this level, drop me a line and we'll see if we can work something out.

The designer model (if you are planning to code-generate from that rather than the compiled assembly) is not formally documented but I'd be happy to write up something on this if required.

I am a source code customer so I will check out the dynamic data source.

But it does get tricky as LightSpeed stores the mapping information on fields but translates that into properties when you query. I never understood how, but now I have to.

I have a WCF Ria Services LightSpeedDomainService running

merging the LightSpeed.DynamicData and the LinqToSQLDomainService source code

It is still pretty basic (and needs refactoring) but generates the Ria services entities and associations without needing to do a special mapping. As long as you follow the convention over configuration mindscape attitude there should be no problems. I am willing to share.

Nice one -- I would be very keen to see this!  Thanks!

I need something very similar to this too, as I am working on a Silverlight app and would love to use RIA services.  Did you make much progress with this?

thanks

@Ivan,

Is the support for RIA Services (Domain Service class) at your roadmap?

Kind regards,
Sörnt

We have been investigating RIA Services, but there appears to be an extremely nasty issue in RIA Services RC2 which may make it impossible for us to complete the work without changes to the way LightSpeed is built and deployed.  We have reported this issue to Microsoft and are talking to the RIA Services team, but they are already starting to lock down 1.0 and can't promise us a fix.

We'll continue to track this issue and seek a workaround if it can't be fixed.

The main problem with WCF ria services and lightspeed is the Id and EntityState not being editable. So you have to hack the source(if you are a source customer) and make them editable or use DTO's.

If you use DTO's and handle the creation of your Entities manually then you can use RIA services out of the BOX.

You dont get the nice meta data classes generated automatically for you with anything but Entity Framework or Linq to SQL.

Ivan did I ever send you my work on the RIA Services Service?

@Middle Tommy

If I get you right, you have extended Lightspeed in a way so that it can provide a DomainService class? If so than Mindescape should have a look at your solution.

Yes, you did send me your RIA Services sample -- for which many thanks.  Unfortunately, they seem to have changed things significantly in the release candidate, and some things no longer work the way they used to.

I hadn't thought of using the DTOs as the domain service classes, but that's a neat idea, especially if we can create a metadata provider that translates LightSpeed entity validation attributes into DataAnnotations attributes on the DTOs (a la the DataAnnotations translator in our Dynamic Data library).

Thanks for the insights -- maybe we'll pick this up again sooner than I'd planned...

Thanks for responding everyone.  Ivan please do post back and let us know how you get on.

Thanks for responding everyone.  Ivan please do post back and let us know how you get on.

Will there be support for Aggregates and DTO's?
How will a DTO know which child Entities needs to be filled?

Using DTO's it is all manual. I am not a RIA services wiz (yet) but as far as I understand it you set up your query and return the DTO instead of the Entity

 public IQueryable<SimplePO_DTO> GetPONumbers()
        {
            return POUnitOfWork.POs.Select(p =>new SimplePO_DTO{PONumber = p.poNumber,Vender =p.Vender != null ? p.Vender.Name : ""}).OrderByDescending(p=>p.PONumber);
        }

SimplePO_DTO is a smaller PO with only two properties. I use this DTO to return a smaller list of all my POs but I could have made full PO DTO's. The only catch with aggregates is that you cant lazy load. You will have to materialize all the associations you want in the query method. Also I believe you will have to create a meta data class for you DTO that includes the Association to another DTO.

something like:

[MetadataTypeAttribute(typeof(PoDto.PoDtoMetadata))]
    public partial class PoDto
    {

        internal sealed class PoDtoMetadata
        {

            private PoDtoMetadata()
            {
            }
            [Include]
            public List<PoItem> Items { get; set; }

            public long PoNumber { get; set; }

            public string Vender { get; set; }

}

}

In the IQueryable returned by your domain service query method you can use aggregates and all the lightspeed stuff you want. On the silverlight side you are limited by the Ria services query options to filter the IQueryable (and that is true for any ORM you use with Ria Services)

Sorry if you already knew this

I guess you dont lazy load aggregates thats the whole point of the aggregate isnt it? But you cant lazy load associations in Ria Services

Let me explain the problem I see:

a) I guess Ivan will create DTO that have allready the necessary "RIA Attributes" (DataAnnotations)

b) The DTO will have a construction with a parameter of the releated EntityType, so the DTO is able to copy the values from the Entity his own properties.

The problem:

The DomainClasse query methods returns IQuerable<DTO> (needed by the RIA Service Framework). The Client can ask to skip the first n entites and get the following 10. The query will be executed deferred. So I shouldn't materialize the query within the query method because I can end up to fetch the whole table.

The select statement will look something like that:

from

  e in MyEnity.WithAggregate("FetchAlsoSomeRelatedEntities")

where

  X=Y

select new DTO(E)

The Domain class query sould return E + some related entities (as specified at aggregate).

What is needed is a parameter and some logic for the DTO constructor (or maybe a helper class for filling the DTO) so it can create the related entities and copy the values.

Also: I can't scope the UOW to the method because of the deferred execution.

So I am not to sure if a simple DTO with some RIA attributes is enough.

Kind regards,

Sörnt

I am whining at a high level :-)

DTO != Entity: Fetch only the values you need for the current business case. So you "should" shape the DTOs to the current business case.

When DTO=Entity whe have some more RAD feeling within the RIA Stack. Nice for prototypes.

Yeah I know how you feel

if only lightspeed would form queries from DTO's or POCO (no base entity)

sometimes the Entity is too heavy

I never thought about the Unit of Work lifetime problem.

(Honestly I have been using Entity Framework for my Ria services Prototyping and I dis-like it) I feel like droping it all and writing a small Lightspeed WCF (Ria services alternative). I already figured out how to have client side Linq Querying work (well it works in my head not that any code has been attempted) using parts of the Dynamic Linq query library from MSDN to serialize linq queries

I see your whining and raise you a little whining and dreaming

You will lose a lot if you drop RIA Service in favour for your own Lightspeed WCF Framework.

In my opinion the Ria Service is near to perfect:

At the server:
- Customizable endpoints
- Clear methods for insert/Update/Delete
- Security

At the clients:

- no re-typing for the Entities/DTOs
- change tracking
- transfer of validation rules
- async method invocation.
- Shared Code (FileName.Shared.cs - Silverlight only)

For me the RIA Services looks to the best middle tier technolgie around (of what MS has to offer) .

Any Client, centralized Domain logic, customizable Entity/DTO transfer - sweet :-)

Some problems I found so far:
- Entity-Types can't be shared across different DomainClasses
- I wasn't able to transfer self-referencing Entites.

Some endpoint configuration I recently found:

<endpoints>
 <add name="JSON" type="Microsoft.ServiceModel.DomainServices.Hosting.JsonEndpointFactory, Microsoft.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

 <add name="OData" type="System.ServiceModel.DomainServices.Hosting.ODataEndpointFactory, System.ServiceModel.DomainServices.Hosting.OData, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

 <add name="Soap“ type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory, Microsoft.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

</endpoints>

what are your thoughts on possible next steps with this in mind MiddleTommy?

I am waiting for Mindscape at the moment. Since programing is my 4th (but favorite) hat at work.

in trying to implement a domain service that return Lightspeed generated entity objects, I get the following error on build:

Error 1 Entity 'PurpleQuote.SupplierAdmin.Web.Models.VehicleMileageRate' has a property 'Errors' with an unsupported type. PurpleQuote.SupplierAdmin

Errors is defined on the Entity base class, so you have to use the metadata provider to either apply the ExcludeAttribute or (probably easier) just to remove it from the property descriptor collection.  You'll run into similar issues with some of the other Entity base properties.  MiddleTommy can probably give you more detailed advice than I can, but what I did was basically this (in my custom type descriptor class):

      private static readonly string[] _excludes = new string[] {
        "Errors", "ChangeTracker", "EntityState", "Error", "IsValid"
      };

      public override PropertyDescriptorCollection GetProperties() {
        List<PropertyDescriptor> pds = new List<PropertyDescriptor>();
        foreach (PropertyDescriptor pd in base.GetProperties()) {
          if (_excludes.Contains(pd.Name)) {
            // skip 'em
          } else {
            pds.Add(pd);
          }
        }
        return new PropertyDescriptorCollection(pds.ToArray(), true);
      }

(You could simplify this using LINQ but my original code was doing some other stuff which is why it has the explicit loop.)

Hope this helps!

You must create a Metadata class for each entity you use and Exclude certian properties.

Id, IsValid, Error, Errors, EntityState, Item, ChangeTracker

you could create a baseMetadataClass that sets all this up and then derive each metadataclass from that

you will also have to create a fake Id Property in your entity that will allow updating and deleting. otherwise your entity will have no Id when it comes back from the client.

something like

/////////////////

[Transient]private long _dtoId;

public long dtoId

{ get { return Id;} set {_dtoId = value;}}

        protected override object GeneratedId()
        {
            return dtoId;
        }
///////////////////////

I think that should work?

That dtoId property wouldnt work here is a Fix

public long dtoId

{ get{return _dtoId;} set {_dtoId = value;}}

Or you could check if your Id has a value and return it otherwise return _dtoId

thanks for the replies, will give it a try tonight.

in the meantime, do you have any insight into why these properties cause an error to begin with, are they not serializable or is it something else?

I believe it is because they are not serializeable.

To me Ria Services is a bit picky on what is serializeable.

Like parameters to queries on a domain service can only be primative pre determined serializeable types

forgive me if this is a stupid question, i don't have access to the source so i'm just guessing.  Can we not just mark those type with the serialisable attribute or implement the serializable interface? 

If that works you then don't need to worry about creating domain specific types and you can handle the unitofwork issue by overriding the domain services dispose method...

That may work for some of them but others are ReadOnly. And ReadOnly Properties dont do Two Way serializing very well. Plus they are LightSpeed specific properties that would not be usefull on the client. As on the client you have a RiaServices Entity not a LightSpeed one. It is best to just exclude them.

Hi there, I tried this and I got it to a stage where it would build without errors and complaints about various properties.  It looks like now the client versions of the Entities are not being generated fully.  They are missing all the column properties. 

Something of note is that I get the following warning on build:

Warning 1 An error was encountered attempting to read the PDB file for 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\532f58c0\c71e955c\assembly\dl3\246a819b\0091b737_18ebca01\Mindscape.LightSpeed.DLL' so it will not be possible to detect shared files in that assembly.  Exception from HRESULT: 0x806D0014 PurpleQuote.SupplierAdmin

any input / ideas from anyone?

I have not yet dealt with .Net 4.0 WCF Ria Services. Ivan suggested things have changed and my code doesnt work anymore. That said, perhaps you need to exclude all properties from the LightSpeed base Entity & Entity<T> classes so code generation wont look for them?

You would be the first ORM solution which supports WCF RIA Services !!!

I can't wait !!!

Any news about support of RIA services by LightSpeed ???

I have a working LightspeedDomainServce<T> where T is a unitofwork and it properly generates Ria Services Entites from LigthspeedEntites.(actually it is a merge of the Lightspeed Dynamic Data project and the LinqtoSQLDomainService project)

The only problem is I modified Ligthspeeds Source in a couple key areas to make it compatible with the Ria Services World.

I made Id settable (meaning once it is set you can not set it again). This is so serialization of Entities (for updates and deletes) works without custom redundant crap.

I made a method Entity.SetEntityState(EntityState state) so The Base LightspeedDomainService can change the EntityState when Updates or Deletes occur to comply with Ligthspeeds EntityState pattern.

I made it so you can turn off Lazy Loading in a unit of work(Actually My LightspeedDomainService has a NewUnitOfWork property that turns LazyLoading off by default) to make any eager loading or agrregate loading an [Include] metadata. The problem is with aggregate loading and RiaServices. I dont think RiaServices has a way to turn off the IncludeAttribute. Turning off Lazy Loading solved the problem of RiaServices LazyLoading data taking extreme amounts of time. This also gives you the ability to use aggregates or not to use them.

I am willing to share if you are a source code customer (my code of course and not my modified Lightspeed code)

The changes to the source I made are less than 10 lines of code.

Can the same changes be incorporated by overriding the behaviour of some key Lightspeed classes without modifying the source?

I will look into it.

I don't suppose you had a chance to think about this some more?

I do think it is possible. but would take some work

You would have to create a dummy Id property for serialization then use the testing tools for ligthspeed to recreate the entity serverside. I could make the Library do this if we settled on a set dummy property name like sId (for serializable Id) in your code just create an sId on each entity

The catch is in the UnitofWork Lazy Loading and Named Aggregates. Without the change of LightSpeed to turn off lazy loading, named aggregates are extremely slow because Ria services will load each association one at a time. The option is to change the library to only put an Include attribute on EagerLoaded associations without named aggregates.

Are these changes acceptable?

Hi Tommy,

I'm very interrested by your 10 lines of code, espacially in order to add the Id Property in your entity that will allow updating and deleting.

Please, can you share your code?>

Thank in advance.

Jonathan.

Johnathan,

Are you a source code customer?

Hi Middle Tommy, thanks for your reply !

I purchased Lighspeed yesterday without sources.

BUT, I'm ready to purchase source code (this was confirmed by the order department with a discount ticket ...).

I would just have an idea about the kind of modification the Id setter requires. If it takes only 10 lines of code, why the feature isn't implemented in the distributed version. There is any side effect for the Lighspeed envirenment?

Thanks  for you help.

Jonathan.

JD,

Is it ok I post my changes to the core library to allow compliance with Silverlight Ria Services? I will only post the changes and where to change them.

Hi guys,

Thanks for checking - yes, you're welcome to share your changes Tommy :-)

As an aside, we are looking hard at improving support for RIA services and these types of scenarios in the next major release of LightSpeed as we know these scenarios could work better out of the box.

Cheers,

 - JD

Hi JD,

that is fantastic news :-)

Best regards,
Sörnt

First Change:

Add this to the Id Property of Entity<T>

set
            {
                if(Equals(_id, default(TId)))
                {
                    _id = value;
                    OnPropertyChanged("Id");
                }
            }

Second Change:

Ah on second thought I will set up a project on Git Hub with the Changes to Make and the whole LightSpeed Ria Services Library I wrote.

Thanks for your share !!!

I'm waiting for the next step ! :-)

The Changes and Library are at

http://github.com/MiddleTommy/LightSpeed-Ria-Services/tree/master

I will post some sample uses shortly

In the GitHub project

Example.cs has an expample usage of the LightspeedDomainService

ChangesToLightSpeedSource.cs shows where to change the source code to be compatible with the library.

Remember in the library all EagerLoaded and Aggregate Loaded associations are automatically Attributed as [Include]. Associations are Automatically attributed also.

I have not done any testing or work on multi key associations. It was not a feature of Lightspeed when I started this project.