This question is locked. New answers and comments are not allowed.
I have a general question related to how is best to handle interaction between business objects and ORM objects.
The two approaches I have used so far are as follows:
1. Store ORM Object - In this approach I get the "customer" orm object using linq and then store it as a private/protected variable in the business object. My business object properties simply get or set the underlying orm objects properties.
The big problem I have found with this approach is that once I have retrieved an orm object I also need to persist the context as you cannot fetch from one context and update in another. I either need to store the context with the object in my class ro store it globally - neither of which I like.
2. Populate Business Object - My second approach was to retrieve the customer orm object then map the properties of this object to the properties of my business object. So far so good. The problem I have found with this approach is that when saving changes, instead of updating the record based on its ID, it always inserts a record when I create a new orm object. The only way around this appears to be to query the database for the orm object first, then update it and save the changes. I don't particularly like this approach either as it involves me having to query the database before actually updating the object which seems unnecessary.
My business objects are shared between desktop, web and mobile applications. How would you guys approach this or what is the recommended/best way forward?
Thanks
The two approaches I have used so far are as follows:
1. Store ORM Object - In this approach I get the "customer" orm object using linq and then store it as a private/protected variable in the business object. My business object properties simply get or set the underlying orm objects properties.
The big problem I have found with this approach is that once I have retrieved an orm object I also need to persist the context as you cannot fetch from one context and update in another. I either need to store the context with the object in my class ro store it globally - neither of which I like.
2. Populate Business Object - My second approach was to retrieve the customer orm object then map the properties of this object to the properties of my business object. So far so good. The problem I have found with this approach is that when saving changes, instead of updating the record based on its ID, it always inserts a record when I create a new orm object. The only way around this appears to be to query the database for the orm object first, then update it and save the changes. I don't particularly like this approach either as it involves me having to query the database before actually updating the object which seems unnecessary.
My business objects are shared between desktop, web and mobile applications. How would you guys approach this or what is the recommended/best way forward?
Thanks
5 Answers, 1 is accepted
0
Hi Mike,
Here are my comments on the approaches that you have posted:
Approach 1: Wrap the entity (ORM object) in your business object
This can work, but your business objects will have a dependency to the data layer/model project. If it is OK for you then ignore this point. The other problem is that you need a living context in order to use the entity instance properly. You can avoid this problem by using Attach/Detach API that lets you cut the link between the context and the entity. That way you can load an entity in a short living context A and later persist it using another context instance B.
Approach 2: Copy values from the entity to your business object
This approach is a popular one when using services. Usually the business objects are called DTO (Data Transfer Object) and have no business logic inside, just data and some validations. The DTOs are convenient way to reuse types across different layers or client implementations since they are just plain classes with no dependencies and can easily be serialized. The problem with them is that it is tedious work to load and synchronise them with their respective entity instances. And you are right - you have to load the entity first, then set the new values and then persist it. This overhead could be used for concurrency checks to see if anyone else has updated the data meanwhile. Again you can skip the loading manually the entity object by using Attach/Detach and setting the right primary key values.
There is a third option - just use Attach/Detach and work with the entity classes. Based on the limited information that I have about your project details I can only put this on the table. You should evaluate if this is applicable to your scenario.
You can find more information about our Attach-Detach API in this documentation article and if you are not familiar with Fetch Strategies you can read this Getting Started guide, since they are very important when working with entity graphs and Attach-Detach API.
If you have any further questions we will be happy to assist you.
Regards,
Viktor Zhivkov
the Telerik team
Here are my comments on the approaches that you have posted:
Approach 1: Wrap the entity (ORM object) in your business object
This can work, but your business objects will have a dependency to the data layer/model project. If it is OK for you then ignore this point. The other problem is that you need a living context in order to use the entity instance properly. You can avoid this problem by using Attach/Detach API that lets you cut the link between the context and the entity. That way you can load an entity in a short living context A and later persist it using another context instance B.
Approach 2: Copy values from the entity to your business object
This approach is a popular one when using services. Usually the business objects are called DTO (Data Transfer Object) and have no business logic inside, just data and some validations. The DTOs are convenient way to reuse types across different layers or client implementations since they are just plain classes with no dependencies and can easily be serialized. The problem with them is that it is tedious work to load and synchronise them with their respective entity instances. And you are right - you have to load the entity first, then set the new values and then persist it. This overhead could be used for concurrency checks to see if anyone else has updated the data meanwhile. Again you can skip the loading manually the entity object by using Attach/Detach and setting the right primary key values.
There is a third option - just use Attach/Detach and work with the entity classes. Based on the limited information that I have about your project details I can only put this on the table. You should evaluate if this is applicable to your scenario.
You can find more information about our Attach-Detach API in this documentation article and if you are not familiar with Fetch Strategies you can read this Getting Started guide, since they are very important when working with entity graphs and Attach-Detach API.
If you have any further questions we will be happy to assist you.
Regards,
Viktor Zhivkov
the Telerik team
Using Encrypted Connection Strings with Telerik OpenAccess ORM. Read our latest blog article >>
0
Mike
Top achievements
Rank 1
Rank 1
answered on 11 Apr 2013, 09:48 AM
Hi Viktor,
Thanks for the response. I'll have a run through the various links you've sent.
I have another issue I'm currently fighting and don't know if you can help me.
I have several join tables (customerorders is an example) that I would like to include in my entity diagram. Unfortunately the telerik wizard imports them as join tables meaning I cannot access the customerorder entity and instead need to use customer.orders or order.customers.
Do you know how I could include the join table as an entity?
Thanks
Mike
Thanks for the response. I'll have a run through the various links you've sent.
I have another issue I'm currently fighting and don't know if you can help me.
I have several join tables (customerorders is an example) that I would like to include in my entity diagram. Unfortunately the telerik wizard imports them as join tables meaning I cannot access the customerorder entity and instead need to use customer.orders or order.customers.
Do you know how I could include the join table as an entity?
Thanks
Mike
0
Hi Mike,
Why would you like to manage manually the records in the join table?
This is an error prone operation that can make your code overly complex.
If you are afraid of some performance issue because you will have to obtain both entities that are to be joined in most cases you should be fine since these entities are already in the memory.
Additionally when you are using the collection navigation properties OpenAccess will calculate the right keys even if one or both of the entities is new.
EDIT: There is a better option:
In Model Schema Explorer in Visual Studio you can select the join table and from Properties panel set IsJoinTable to false. Then you can drag and drop the table to the design surface and map it as a normal class. The option stated below is possible, but inferior.
END EDIT.
If you really need to map the join table to an entity class you can add new nullable column to the table and then update your model from the database. The new column is completely dummy and is needed just to work around the rules that OpenAccess uses to determine which tables are join tables.
Please share the scenario that you have in mind so we can get more insight into it and assist you better.
Regards,
Viktor Zhivkov
the Telerik team
Why would you like to manage manually the records in the join table?
This is an error prone operation that can make your code overly complex.
If you are afraid of some performance issue because you will have to obtain both entities that are to be joined in most cases you should be fine since these entities are already in the memory.
Additionally when you are using the collection navigation properties OpenAccess will calculate the right keys even if one or both of the entities is new.
EDIT: There is a better option:
In Model Schema Explorer in Visual Studio you can select the join table and from Properties panel set IsJoinTable to false. Then you can drag and drop the table to the design surface and map it as a normal class. The option stated below is possible, but inferior.
END EDIT.
If you really need to map the join table to an entity class you can add new nullable column to the table and then update your model from the database. The new column is completely dummy and is needed just to work around the rules that OpenAccess uses to determine which tables are join tables.
Please share the scenario that you have in mind so we can get more insight into it and assist you better.
Regards,
Viktor Zhivkov
the Telerik team
Using Encrypted Connection Strings with Telerik OpenAccess ORM. Read our latest blog article >>
0
Mike
Top achievements
Rank 1
Rank 1
answered on 11 Apr 2013, 03:03 PM
Hi Viktor,
The reason for asking is detailed in a different post:
http://www.telerik.com/community/forums/orm/getting-started/join-tables.aspx
Essentially, as I am populating DTO objects rather than maintaining the entity classes to add a single record to the join table I'm finding I have to execute 4 sql statements. 1 to get the user, 1 to get the role, 1 to get the user_roles and another one to insert the role in the user.user_roles table.
I was hoping to avoid this by simply inserting a single user_role record with the userid and roleid as this seems very inneficient.
Cheers
Mike
The reason for asking is detailed in a different post:
http://www.telerik.com/community/forums/orm/getting-started/join-tables.aspx
Essentially, as I am populating DTO objects rather than maintaining the entity classes to add a single record to the join table I'm finding I have to execute 4 sql statements. 1 to get the user, 1 to get the role, 1 to get the user_roles and another one to insert the role in the user.user_roles table.
I was hoping to avoid this by simply inserting a single user_role record with the userid and roleid as this seems very inneficient.
Cheers
Mike
0
Hi Mike,
This sounds like a reasonable optimization, when you consider that you already have the right IDs from the DTO instances. I guess you were able to implement it already, if not do not hesitate to post your questions.
Regards,
Viktor Zhivkov
the Telerik team
This sounds like a reasonable optimization, when you consider that you already have the right IDs from the DTO instances. I guess you were able to implement it already, if not do not hesitate to post your questions.
Regards,
Viktor Zhivkov
the Telerik team
Using Encrypted Connection Strings with Telerik OpenAccess ORM. Read our latest blog article >>