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.
the Telerik team