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
|
In comparing-lightspeed, please add a row for POCO. Also, in your documentation, explain that LightSpeed doesn't support POCO. In Entity Framework and OpenAccess, the model is POCO and does not know about the ORM. In Lightspeed, the model must inherit from Lightspeed, and so does know about the ORM. This results in each Model being "married" to Lightspeed. So we have a violation of Separation of Concerns. A model now has two concerns. First is the entity, which is its job. Second is that it uses Lightspeed ORM. This is subject to change, if Architect want to use a different ORM. As long as the Architect is aware of this, and decides that the benefits of using Lightspeed greatly exceed the violation of Separation of Concerns, s/he will incorporate Lightspeed into her/his applications. Violating Separation of Concerns can happen, but this should happen as a conscious decision. In this case, the benefits are less configuration, better performance, built in validation, more features, etc. The downside is that if you ever decide to divorce from Lightspeed, that this will require some rework, as each entity has to remove its inheritance and other features from Lightspeed. Personally, I think this is a reasonable trade-off, but should be made explicitly, and not be hidden. This is nothing to be ashamed of, but as an honorable and ethical vendor, this should be made explicit in your comparison page, and also your documentation manual. Respecting the prospect, you notify the prospect that you don't support POCO objects, and they should decide if the trade off makes sense for them. If POCO is a necessity for the prospect, then Lightspeed may not be for them. If they can live without POCO for all the other benefits, then the prospect/Architect may choose Lightspeed with their eyes open, making the hard decisions that Architects need to make. Your job is to be nice and tell the Architects up front that POCO is not supported. I believe that the benefits of Lightspeed greatly outway not having POCO, which is why I am a licensed user. So add a row of "Plain Old CLR Object for each Model Entity" In this case, Lightspeed get an X, and EntityFramework and OpenAccess get a Check mark. I believe Linq to SQL also gets a check mark. I am not sure about EntitySpaces. |
|
|
|
