This is a migrated thread and some comments may be shown as answers.

OA Silverlight support

14 Answers 211 Views

General Discussions

This is a migrated thread and some comments may be shown as answers.

This question is locked. New answers and comments are not allowed.

14 Answers, 1 is accepted

answered on 28 Jan 2010, 05:54 PM

Hello Espen Harlinn,

Originally Silverlight integration is not one of the strongest aspects of our ORM tool. However we are actively working on improving the way Telerik OpenAccess ORM works with Silverlight. What will come next is full support of RIA data services - framework designed to make developer's life much easier. You will be able to work with Ria and OpenAccess with great ease and that will for sure speed up the development of Silverlight enabled applications.

Regards,
Petar
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

answered on 08 Feb 2010, 10:00 PM

Hi Petar,

Thanks for the answer. At this moment we used Delphi Remobjects SDK as a middle tier, plus a silverlight .net client, in combination with Telerik controls for our Silverlight development (using C#). My developer has done some testing with ORM in combination with ADO.net services. We used Oracle as a database. What I heard was (please correct me if I am wrong):

1:1 table to entity mapping
all data will be fetch
more or less only static design
Oracle stored proc which return a result set is not possible (Oracle refcursor)

We used complex queries (multiple joins) with dynamic conditions and used stored procedures extensively. RO handles this without a problem. But this solution gives us more development work. We want to start a new Silverlight project, only with C#(not mixing with delphi), and are a in doubt to develop some work with ado.net services and replacing with Ria services at a later stage. ( replicating work) I suggest telerik should consider a beta. I think many customers are willing to give some feedback about the offered solution i.e. Ria services for ORM….

Regards,

Henk

answered on 11 Feb 2010, 06:12 PM

Hi Henk,

Regarding your questions:
1. By default our classes are generated to reflect your database schema 1:1. However the process is completely under your control. You can easily exclude Tables and or columns from being mapped. It is also possible to add fields that will later be added to your database schema. You can even have fields that are part of your model but not part of your database which means that their data is not persisted
2. Telerik OpenAccess ORM depends on a functionality called fetchplans in order to determine which data should be fetched. You can find more information here.
3. Can you please specify what exactly do you mean by this ? We use several static methods for initiating a scope instances but this does not mean that we are using static design.
4. If you use the GetSqlQuery method of the IObjectScope you should successfully execute such types of stored procedures. Additional information can be found here.

We aim at providing full RIA support for our Q1 release which is scheduled for early March. Unfortunately I cannot guarantee that a beta of the RIA provider will be available prior to the Q1 release.

Sincerely yours,
Petar
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

answered on 14 Feb 2010, 02:53 PM

Hi Henk,

If I understand things correctly you have so far used RemObjects SDK. A product from a company that has successfully developed a framework targeting distributed application development for a long time.

The alternative you are considering is Open Access – a product that is basically an ORM with no proven track record, for all practical purposes it’s still a product under development.

As can be seen from the examples it is certainly possible to develop “toy” demos using Open Access – but will it work in the real world? Given a “real world” database design, is Open Access usable at all? By “real world” I mean a database with more than, let’s say, 50 tables and more than 10 million records.

Take a look at:

http://www.telerik.com/community/forums/orm/linq-questions/i-hope-i-m-wrong.aspx#1069354

Using RemObjects DataAbstract I can get a barely usable server up and running in about half an hour, and a decent one in a couple of days. Combine DataAbstract with allroundautomations.com Direct Oracle Access components and you have the ingredients of a stable and efficient distributed multitier solution using Delphi that’s interoperable with Silverlight, WCF, Windows CE, Java and a number of other scenarios.

Exactly why you would want to throw away, if I understand you correctly, a working solution beats me…

Now I haven’t really used RemObjects for about a year, I’ve changed job – but at that time the documentation was on the poor side as such things go.

With Open Access, Telerik has done a wonderful job. If you go by what they write, you can fairly easily be mislead into thinking that Open Access is a great product providing loads of functionality found nowhere else.

So while using RemObjects DataAbstract will surprise you when it comes to what the product actually can do, Open Access will surprise you when it comes to what the product can’t do.

You can also look forward to sometimes more than 200000 % performance overhead, and that’s not a spelling error, compared to accessing the results of and evaluating queries using System.Data.SqlClient directly – and I expect this is also true for Oracle ODP.Net – this was tested using a relatively small database with less than a million records and evaluating a query against four tables using linq. Obviously your mileage will vary. Picking the query apart and executing it against one table at a time reduces the overhead to about 10000 %, most of which probably comes from the xml based mapping of columns to entity properties. This is with the MS SQL Server and the test application running on the same computer – move the database to another computer and everything gets much worse, and before you know it you have successfully written an application ready to consume all available network bandwidth and then some. This might make Cisco happy, but I’m not so sure about your customers.

The basic reason for this is that when you rip away the antlr generated code together with ports of various open source java projects from Open Access there isn’t all that much left – a bit of state information and caching. Open Access evaluates linq expressions on its own using the database as a dumb data store. It doesn’t matter how efficient they actually evaluates the queries, all the data has to be loaded from the database – they are a long, long way from evaluating them on a performance level comparable to SQL servers like MS SQL or Oracle RDBMS.

Fetch plans are just a way to reduce the number of round trips required to load all that data from the database – it still gets loaded. If you want to avoid all that, the provided mechanisms make programming against DataSet and DataTable seem relatively painless and straight forward.

Remobjects DataAbstract and Developer Express XPO are products that support SilverLight on their own, and I’m sure there are others out there too. With Open Access, you have to rely on something else, like RIA or WCF for getting things across the network – this is partially true for XPO too, but they provide a SilverLight integration that only requires you to provide an implementation of a predefined interface and viola you have intelligent updates based on delta packets.

WCF services generated along the guidelines of Open Access loose most of what could actually be interesting about the product in the translation – state information. IEditableObject and INotifyPropertyChanged is left as an exercise for the programmer – so in most cases, when you actually want to edit a piece of data, you end up writing significantly more code when you base your product on OpenAccess compared to using System.Data.SqlClient directly and mapping operations to a well defined WCF service that you plug into the view model on the Silverlight side.

Open Access is an alternative to NHibernate, MS Entity Framework, MS Linq SQL, and what you find in the System.Data.* namespaces. If you have the full .Net framework available DataSet and DataTable will usually take you further than Open Access with less work and better integration with the rest of the .Net framework.

If you really want strongly typed objects and performance is an issue consider hand coding the data access code and roll your own entities – if performance is not an issue take a look at MS Entity Framework.

Take this together with the ramifications of SOX http://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act and the related ongoing adjustments to laws, regulations and standardization efforts that increasingly govern architecture, design and implementation details related to the IT industry at large.

If you want to be really sure that the product you are developing fits into this picture of mandated control, auditing, and security and so on – you’ll need every bit of performance you can tweak out of available hardware and software resources.

The average database is not going to get smaller, and while there are obvious ways to provide Open Access with only a limited amount of data – requiring you to do so kind of defeats the purpose of an ORM.

I really hope that going forward Telerik will rectify most of the shortcomings of Open Access – either that or scrap the product.

Regards

Espen

answered on 17 Feb 2010, 05:32 PM

Hi Espen Harlinn,

First of all let me share some history with you. The company named Versant has a product branded as FastObjects. FastObjects is an object database (ODBMS) providing an API to deal with objects. Some engineers having defined and implemented that API moved over to create an API supporting ODBMS and RDBMS equally.

Adding Mapping and Runtime to the RDBMS-API made it an ORM, which was brought to market by Vanatec under the brand OpenAccess. It was not until late 2008 when Telerik acquired Vanatec and thus OpenAccess became Telerik OpenAccess ORM being focused on .NET and RDBMS. Please note that in the process OpenAccess faced several code base translations the last one being from java to C#.

As you can see we, at Telerik, are facing huge legacy and you can imagine how hard is to make a change in such a large product. But changes do happen and they are easily notable. If you want to see for yourself you can always download an old version from Q3 2008 and compare it with Q3 2009. You will for sure see how far we have went in improving the product. The process goes on even now. The changes we have prepared for Q1 2010 can be qualified as breath taking. While we understand that our product is far from being perfect we are not wasting any time but investing into improving it and we have to say that we are proud of what we have achieved so far.

Any product can be slow if not used right. While I am not saying that you have made any mistakes I would like to point you out to a site that offers comparison sheets between different ORMs that are out there on the market. I am not sharing this site in order to show you how great our product is. Right on the contrary. We understand the pitfalls of our product and we are not afraid of showing them to our customers as they need to know them when making a decision for their product. What differs us from the other products is the fact that we understand our problems and move forward on solving them. That is an outgoing effort that will not end until our product is in the top of the table.

Sincerely yours,
Petar
the Telerik team

answered on 17 Feb 2010, 11:55 PM

Hi Petar,

As I mentioned near the end of my previous posting, I sincerely hope you’ll rectify the shortcomings of the product; and, yes, I have noticed that you have improved the product, but it’s not suitable for anything but small scale development efforts.

There exists, or at least existed last August, a pdf file for OpenAccess that could easily be misunderstood in terms of what OpenAccess is capable off. Obviously the information contained in that pdf can be read in many ways – and an average developer will usually fail to see the various pitfalls of using OpenAccess. That does not mean I think the product has no place in the market, but in fairness to customers I believe you should be somewhat more cautious in your marketing efforts.

You have after all a reputation to maintain, and many consider you to be a well renowned and reliable provider of development tools and components.

I took a look at the site you referred to, and you’ll have to admit that the test cases are somewhat contrived. The tests could be said favor the dumbest ORM – or the smartest ones, but none of the test results seems to indicate that any of the tested ORMs are doing the smart thing, in which case they should have outperformed the SqlClient implementation.

If I understand things correctly the tests you refer to are relatively small scale – the largest iteration being 30 000 items using an entity that is so simple you’ll hardly ever see it in “real-life”. See: http://www.ormbattle.net/index.php/performance-tests.html

Getting to the top of that table shouldn’t be all that difficult, but it certainly isn’t worth the effort since it will not tell your customers anything really useful about your product.

The test is so small and simple that BLToolkit might even get its stellar score from being the first to run, and thus avoid some of the cache recycling delays, but that’s just a speculation.

The tests could also be said to underscore the difference between “real-life” application scenarios and “toy” demo applications. For a somewhat more interesting test regime take a look at http://www.tpc.org which is all about performance numbers for relational database server configurations and not ORMs. I think you’ll at least agree that they are a bit more serious when it comes to creating a setup for performance testing.

OpenAccess and many other ORMs may be a stellar choice if what you are doing is very small scale, like a personal finance application – 30 000 records would normally be quite enough in this case.

That’s a long way from a medium scale line of business application that could reasonably be expected to handle let’s say 20 000 000 records over a period of ten years. Ten to fifteen years often being mandated by authorities if you are doing stuff that’s directly or indirectly related to accounting and sometimes other legal regulations. In Europe the number of often contradicting laws and regulations pertaining to the IT industry is mind boggling, and growing each year. That’s actually good news for us developers as companies will have to keep spending a significant amount of money on development efforts, but it also means that the amount of data we have to deal with is growing steeply.

In most cases we are dealing with multiple, often nested and possibly interrelated, master-detail views into the database (Customer, order, order details, shipment details, inventory, ledger and so on). Executing queries on the client just isn’t as efficient as doing them on the server, not even close.

I would really love a product that would allow me to write applications that can deal with this scenario for SilverLight, but I’m unable to imagine an efficient solution without something on the SilverLight side of things. My criticism of OpenAccess is based on my experience with the 2009 Q2 and Q3 releases.

Best regards

Espen

answered on 18 Feb 2010, 09:04 AM

If this is the stick you want to be measured against, I'll hardly call it a confidence builder. It also neatly sidesteps the severe performance overhead caused by the OpenAccess XML based entity mapping system.

The ORMBattle.net entity:
public class Simplest
{
..public long Id { get; set; }
..public long Value { get; set; }
}

and the OpenAccess performance tests:
protected override void InsertMultipleTest(int count)
    {
      scope.Transaction.Begin();
      for (int i = 0; i < count; i++) {
        var s = new Simplest(i, i);
        scope.Add(s);
      }
      scope.Transaction.Commit();
      InstanceCount = count;
    }

    protected override void UpdateMultipleTest()
    {
      scope.Transaction.Begin();
      var query = scope.Extent<Simplest>();
      foreach (var o in query)
        o.Value++;
      scope.Transaction.Commit();
    }

    protected override void DeleteMultipleTest()
    {
      scope.Transaction.Begin();
      var query = scope.Extent<Simplest>();
      foreach (var s in query)
        scope.Remove(s);
      scope.Transaction.Commit();
    }

answered on 18 Feb 2010, 08:51 PM

Hi Espen,

Your tone of reply indicates some kind of vendetta against Open Acess ORM. I am not interested in your comments. It is common sense to realize that every layer you make between the data in the database and managing the data using an application will impact performance. In the old days you programmed in assembler, some programs still do. It is the fastest way to do some number crunching etc. When the first rdbms appears in the market proponents of hierarchical and network databases criticized the performance of an rdbms. You may remember 1,2,3 4 GL programs and the discussions about the pro and the cons using this development tools. Not so long ago, the internet became popular and managers required internet enabled application. Because of business, security, specialization of development work and others valid reasons, multi-tier architecture gaining more importance. Developers using more and more object oriented languages for their development work, but the database used still remains an rdbms. So the world of ORM tools appears to solve relational structure against the object oriented development process. In the future vendors will offers developers more and more pre-fabric building blocks for a specific task without programming all the modules inside such a prefab software solution. My point of this story? Performance! You will always loose performance against a bare metal solution.

If you’re not born rich or you are not a top programming genius, or you don’t have unlimited time for playing with performance but you have limited resources then you accept the performance penalty using 3third party component solutions. If performance is an issue we will feedback the vendor and switch to another vendor when our issues of feedbacks are not solved or responded.

We have good experience with Remobjects and with Telerik. Both companies are quite responsive about our wishes and questions.

Don’t start another thread in response of this response. Again, I am not interested to respond to an opinion when the person already shout he knows the best solution….

Regards,

Henk

answered on 18 Feb 2010, 11:19 PM

Hi Petar (and Henk, maybe .. :-) )

From my point of view: a version of OpenAccess that successfully catered to my needs as a developer would be great. I don’t have a vendetta against OpenAccess, but please take a look at http://www.telerik.com/products/silverlight/resources/silverlight-performance.aspx#grid-performance-example. Obviously other parts of Telerik are well aware of the need for components that can handle huge amounts of data.

As has been previously stated: Telerik is in the process of revamping the product, and if my input could in some small way make them rethink some part of their strategy for OpenAccess – in particular with regard to better handling of more complex database designs and larger databases, that would benefit me.

Obviously Telerik has to prioritize which aspects of OpenAccess they should focus their development efforts on. From what I’ve seen their focus is currently on Linq and RIA integration. I would dearly like to see them turn more of their focus towards performance and large databases.

If I don’t tell them what I want from them, and argue as hard as I can, why should they rethink their current strategy?

Since Linq expressions in OpenAccess are evaluated by OpenAccess (see: http://www.telerik.com/community/forums/orm/linq-questions/i-hope-i-m-wrong.aspx ) instead of using the AST to generate a query that can be passed on to the RDBMS, the OpenAccess team has at least one alternative open to them that could greatly enhance the scalability and performance of the product.

If that kind of functionality where integrated with SilverLight, and by doing so bypassing much of the processing that will be required on the middle tier using the RIA integration approach, you can hopefully end up with a product that will utilize the available computer resources extremely efficiently.

So pardon me for mentioning that some other vendors have thought that this is a good idea too.

Henk wrote: It is common sense to realize that every layer you make between the data in the database and managing the data using an application will impact performance.

Is it? Just like database vendors ORB vendors can benefit from investing some development effort into optimizing how they access the underlying storage technology. For ORB vendors the most obvious, and easiest optimization to implement, is to turn multiple statements into compound batches. One can easily imagine that transferring a 100 inserts at a time to the RDBMS would have great implications for the performance of the ORM.

Henk wrote: If performance is an issue we will feedback the vendor and switch to another vendor when our issues of feedbacks are not solved or responded.

To me performance is an issue, and not only am I trying to tell them [Telerik] so – I’ve also taken the trouble of investigating the product, as in RTFS, so that I’m able to specifically point to a number of areas within OpenAccess where there is a significant potential for performance gain and not inventing stuff out of whole cloth:

Parsing the embedded App.inf is expensive, especially for complex databases – the table mapping functionality can be rewritten as arrays and embedded in the generated source code, potentially for each supported RDBMS.
Move as much as possible of the query processing to the RDBMS
Analyze the RDBMS and utilize information about available indexes
Optimize the required number of roundtrips between the client and RDBMS.
Move some of the ORMs functionality to SilverLight.

Wanting these things can hardly be wrong, and if I thought that this was beyond the capabilities of Telerik I wouldn’t even have bothered to point them out.

When Petar refers to ORMBattle.net, I must say that I became somewhat miffed – I somehow expected better from Telerik; and the reason should be obvious from the source code of the “tests”.

Regards

Espen

answered on 19 Feb 2010, 01:26 PM

Espen, thank you for going at such lengths to prove your point - we like your feedback and have already logged some ideas in our database! Hopefully you will see some of your ideas implemented in the near future.

Henk, we are grateful for your advocacy! Happy customers always make us happy!

We do not want to take sides in this argument, because the bottom line is that absolutely all clients are important for us, and all feedback is precious. We see value in the fact that the current standing of the product is good enough to be used among the majority of developers, and we also see value in the fact that you guys drive us to push the envelope further, by requesting improvements and new features. Performance *will be* the main driving force in the next couple of years and we defiantely have plans to ride this wave!

Anyway, there is no need to argue - Telerik is here to address all of your needs, and we will do our best to so, as Peter pointed out.

Thank you for your support!

Kind regards,

Vassil Petev (vpetev _at_ telerik_com)
Unit Manager
the Telerik team

Product Bundles

DevCraft

Web

Mobile

Document Management

Desktop

Reporting & Mocking

Automated Testing

CMS

UI/UX Tools

Debugging

Free Tools

OA Silverlight support

14 Answers, 1 is accepted