This question is locked. New answers and comments are not allowed.
Hi guys,
I used to use OpenAccess when it was still "classic" as you now call it, and I'm evaluating it again for a new customer/project, in it's new form. We had great success using the previous incarnation, but I have to say so far using the new version is considerably worse than banging my head against a brick wall... something more like banging my head into a wall covered with nails, and when I finally make it through the wall, I find my head precisely in the target position for the sledgehammer quality control testing machine in the sledgehammer factory on the other side of the wall, where my head stays stuck, used for sledgehammer testing every 10 seconds.
So to the question posed in the post title...
The documentation for associations says navigational properties are optional, for either end of an association, but if I try and remove a navigational property in the designer, from either end, I'm told I can only remove the navigational property by deleting the association... who's right?
And now in case you're feeling generous, some of the other issues I've encountered:
1) I built a model-first domain model, by building the tables, then mapping them in the designer as detailed in the documentation, but all my entity properties are mapped as Object, despite them being int, varchar, etc in the tables. Seems a little wrong?
2) Even if I do build, map, generate the schema, update the model, etc, etc, (way too many steps here guys, "classic" wizards were simple compared to this, and they were some of the most complicated wizards ever), I do not get a context object in my project? The EntityDiagrams object has a method for get context, but I have no strongly typed context object.
3) On the mapping details - relationships panel/window, what do the Managed and Dependent check boxes do? I can't find a reference for them in the documentation. I will happily admit to not having read the entire docs, but I read all the likely topics and can't see them mentioned. Additionally, when I do find a screenshot of this panel under the Mapping Details Editor topic, the managed check box is not even shown. It seems pretty clear that the documentation is out of date, which I find pretty disappointing for a product this complex.
4) This is just a personal whinge... why does it feel like all your dialogs are half finished, and the product of a work-experience student's last few days with your company? This, I admit, is probably/possibly a personal thing so please feel free to ignore me, but the dialogs just feel like they've been thrown together to get the particular feature implemented, but no thought was really given. They are pretty unintuitive and coming from a company that makes BEAUTIFUL stuff like the WPF Scheduler, it's a bit disappointing. The reason I give so much feeling to this is it feels like the companies investment in the ORM product might be declining, and I'm not going to send a customer down a path that may be a dead end in 6/12 months time.
I apologise for what may appear to be a torrent of abuse, but I assure you it comes from a good place. I have had a relationship with your products for at least 6 or 7 years now, and I have to be honest a say I feel let down by this latest ORM edition. It feels like you guys jumped too far too fast in trying to re-design the product, and I think you should have that feedback in an honest form.
I hope you can see that I'm not attacking you for fun, just looking for reassurance from a long-standing partner.
Kind regards,
Adam.
I used to use OpenAccess when it was still "classic" as you now call it, and I'm evaluating it again for a new customer/project, in it's new form. We had great success using the previous incarnation, but I have to say so far using the new version is considerably worse than banging my head against a brick wall... something more like banging my head into a wall covered with nails, and when I finally make it through the wall, I find my head precisely in the target position for the sledgehammer quality control testing machine in the sledgehammer factory on the other side of the wall, where my head stays stuck, used for sledgehammer testing every 10 seconds.
So to the question posed in the post title...
The documentation for associations says navigational properties are optional, for either end of an association, but if I try and remove a navigational property in the designer, from either end, I'm told I can only remove the navigational property by deleting the association... who's right?
And now in case you're feeling generous, some of the other issues I've encountered:
1) I built a model-first domain model, by building the tables, then mapping them in the designer as detailed in the documentation, but all my entity properties are mapped as Object, despite them being int, varchar, etc in the tables. Seems a little wrong?
2) Even if I do build, map, generate the schema, update the model, etc, etc, (way too many steps here guys, "classic" wizards were simple compared to this, and they were some of the most complicated wizards ever), I do not get a context object in my project? The EntityDiagrams object has a method for get context, but I have no strongly typed context object.
3) On the mapping details - relationships panel/window, what do the Managed and Dependent check boxes do? I can't find a reference for them in the documentation. I will happily admit to not having read the entire docs, but I read all the likely topics and can't see them mentioned. Additionally, when I do find a screenshot of this panel under the Mapping Details Editor topic, the managed check box is not even shown. It seems pretty clear that the documentation is out of date, which I find pretty disappointing for a product this complex.
4) This is just a personal whinge... why does it feel like all your dialogs are half finished, and the product of a work-experience student's last few days with your company? This, I admit, is probably/possibly a personal thing so please feel free to ignore me, but the dialogs just feel like they've been thrown together to get the particular feature implemented, but no thought was really given. They are pretty unintuitive and coming from a company that makes BEAUTIFUL stuff like the WPF Scheduler, it's a bit disappointing. The reason I give so much feeling to this is it feels like the companies investment in the ORM product might be declining, and I'm not going to send a customer down a path that may be a dead end in 6/12 months time.
I apologise for what may appear to be a torrent of abuse, but I assure you it comes from a good place. I have had a relationship with your products for at least 6 or 7 years now, and I have to be honest a say I feel let down by this latest ORM edition. It feels like you guys jumped too far too fast in trying to re-design the product, and I think you should have that feedback in an honest form.
I hope you can see that I'm not attacking you for fun, just looking for reassurance from a long-standing partner.
Kind regards,
Adam.
1 Answer, 1 is accepted
0
Hi Adam,
Your feedback is highly appreciated and will be taken as constructive criticism.
The main reason to begin the visual designer project was that the classic approach had come to the limits of its extension capabilities and there was no way to satisfy the new needs of our clients. You are probably right that some of the designer areas are not 100% covered yet and may look unfinished or not polished enough. However, we believe that the designer has already covered most of the functionality provided by the classic wizards, which was actually the main target we were aiming at the last year. Since the Q3 release, our main goal is to improve the weak areas of the product and not to introduce so many new features.
Regarding the usability problems you mentioned, they could be caused by the big difference between the classic and the new visual approach. If you have already used to the old wizards, it could be a bit frustrating to start using the product the new way. If you do not want to invest time in learning how to work with the designer, you can still use the old wizards if they work for you, we have no plans to get them out of the product any time soon. Nevertheless, you are encouraged to send us any feedback regarding the experience you have with the product, your suggestions will surely be taken into account. Maybe at some point you will reconsider switching to the designer, once you see that it is mature enough to suit the needs of your projects.
Now let me answer your technical questions.
At the moment it is not possible to have in the designer an association with only one end but this will be supported at some stage. We will remove the misleading information from the documentation until this happens.
1) This indeed turned out to be a problem with the initialization of the type converters used for converting CLR types to SQL types and vice versa. Closing and opening the newly added rlinq file should avoid this behavior until we fix the actual problem.
2) The EntityDiagrams class is actually the context class of your domain model. It contains an IQueryable<T> endpoint for each persistent class in the model which you can use for linq queries. Methods for Adding and Deleting objects are also available. Another difference to the IObjectScope is that transactions are handled automatically and you need to call only SaveChanges() or ClearChanges() to commit/rollback the transaction.
3) The dependent option corresponds to the "cascading delete" option from the old wizards. If enabled, the collections of referenced objects are deleted from the database together with their parent object.
The managed option is not a new one either. When it is enabled the two ends of an association are kept in sync automatically and setting the reference on one of the association ends is enough. The other will be updated by OpenAccess. This option has been added recently to the designer but you are right that the documentation is not updated yet. I will make sure this is fixed soon.
Again, thank you for your feedback and do not hesitate to share with us any other thoughts about our products.
Regards,
Alexander
the Telerik team
Your feedback is highly appreciated and will be taken as constructive criticism.
The main reason to begin the visual designer project was that the classic approach had come to the limits of its extension capabilities and there was no way to satisfy the new needs of our clients. You are probably right that some of the designer areas are not 100% covered yet and may look unfinished or not polished enough. However, we believe that the designer has already covered most of the functionality provided by the classic wizards, which was actually the main target we were aiming at the last year. Since the Q3 release, our main goal is to improve the weak areas of the product and not to introduce so many new features.
Regarding the usability problems you mentioned, they could be caused by the big difference between the classic and the new visual approach. If you have already used to the old wizards, it could be a bit frustrating to start using the product the new way. If you do not want to invest time in learning how to work with the designer, you can still use the old wizards if they work for you, we have no plans to get them out of the product any time soon. Nevertheless, you are encouraged to send us any feedback regarding the experience you have with the product, your suggestions will surely be taken into account. Maybe at some point you will reconsider switching to the designer, once you see that it is mature enough to suit the needs of your projects.
Now let me answer your technical questions.
At the moment it is not possible to have in the designer an association with only one end but this will be supported at some stage. We will remove the misleading information from the documentation until this happens.
1) This indeed turned out to be a problem with the initialization of the type converters used for converting CLR types to SQL types and vice versa. Closing and opening the newly added rlinq file should avoid this behavior until we fix the actual problem.
2) The EntityDiagrams class is actually the context class of your domain model. It contains an IQueryable<T> endpoint for each persistent class in the model which you can use for linq queries. Methods for Adding and Deleting objects are also available. Another difference to the IObjectScope is that transactions are handled automatically and you need to call only SaveChanges() or ClearChanges() to commit/rollback the transaction.
3) The dependent option corresponds to the "cascading delete" option from the old wizards. If enabled, the collections of referenced objects are deleted from the database together with their parent object.
The managed option is not a new one either. When it is enabled the two ends of an association are kept in sync automatically and setting the reference on one of the association ends is enough. The other will be updated by OpenAccess. This option has been added recently to the designer but you are right that the documentation is not updated yet. I will make sure this is fixed soon.
Again, thank you for your feedback and do not hesitate to share with us any other thoughts about our products.
Regards,
Alexander
the Telerik team