This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Entity Framework uses Plain Old CLR Objects or POCOs to represent Entities. This results in the Entity not being aware of Entity Framework. But with LightSpeed, the Entity inherits from LightSpeed. I understand that lots of goodness comes from this. Such as much simpler configuration Have we bound ourselves to Lightspeed, in that it is now a BIG job to convert to Entity Framework? Do we lose the ability to do simple unit tests? What have we given up by not using POCOs? Thank you. |
|
|
|
|
What problems are you actually seeing? Particularly with regard to testing. LightSpeed Entities is certainly heavier weight objects because of the underlying functionality in the base class but they are still just class instances when you are dealing with them ordinarily. The key inferred coupling with something external is to the UnitOfWork when thinking about the ability to lazy load child collections etc. As an aside you can work with POCO's with LightSpeed by having a seperate POCO model and map to these from your LightSpeed entities and then use UnitOfWork.Import to re-attach them later for persistence.
|
|
|
|
|
Please provide sample project using LightSpeed with POCOs. Or provide where in documentation to find out how to uses POCOs with Lightspeed. |
|
|
|
|
Here is a blog post from when we originally implemented this detailing the use of UnitOfWork.Import: http://www.mindscapehq.com/blog/index.php/2011/03/08/dtos-and-pocos-in-lightspeed-4/
|
|
|
|
