7 Answers, 1 is accepted
Henrik is correct, those options are basically the two approaches you have at your disposal when working with OpenAccess ORM:
1) Visual Designer approach (where the rlinq file is the model definition) - you can work visually with your model, apply the changes to the database or get schema changes from the database. You can work Model First or Database First.
2) Fluent Mapping - you are defining the mapping declaratively through code. The approach is much more flexible, but a bit harder as a matter of coding effort.
You can get the most out of the two approaches if you combine them by using Fluent mapping type when you are adding an rlinq domain model as shown here. However, there are some limitations you need to be aware of should you choose this approach - they are described in a documentation article.
Let us know if you have any further questions.
Ivailo
the Telerik team
Thank you Ivailo for the links. I will read on with your links and will test a bit.
Erik
There are two sides to the story, first it is obvious that working with a huge model and fluent will require a little bit more in terms of maintenance, however the bigger the model gets the harder it gets to work with the designer, as soon as you hit 500 entities you will face certain trouble with reponsiveness of the diagram.
What you should also take into consideration is the fact that the FluentAPI provides more (and more advanced) features than the designer. You will not get to map dictionaries, structs or use polymorphic references through the designer.
Another thing to think about is the designer wizard, that you will not be able to use with fluent, for example Upgrade From Database applies all changes to the database to your model and creates new classes for you, using the fluent you will need to either work model first, or parallely work on the schema and classes (and fluent mapping).
In a few words working with the designer is easier and faster, and if you are spiking or have no time to spare, I would suggest that you use that. However if you want full control of your model, more features and a nice code only approach, then you should use the Fluent Mapping.
(Of course, if you already have a huge database that needs mapping, there isn't much sence in going Fluent, as the initial effort of mapping everything will be quite small when using the designer).
I hope this is helpful.
Serge
the Telerik team
I know that when a model grows, EF Code First begins to take a hit when an application starts up. Essentially, the mapping has to be loaded on application start. There is a possibility to Pre-Generate Views in EF Code First which can help startup time, but I've found it works only some of the time and it can be problematic.
Does OpenAccess Fluent mapping suffer the same types of issues? Do you know if with a large model there would be an advantage of using the OpenAccess Fluent mapping over EF Code First? If I go the fluent mapping route, am I going to pay a price later on when the model grows in size?
Thanks,
Warren
Generally you should not get any performance hit with your model increasing in size. It is true that during application start we do spend some time in metadata calculation but that time is usually less then a second even with 300+ classes in a model.
Regards,Petar
the Telerik team