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
|
Very interesting ORM... but:
|
|
|
Hi Svetloyar, Thanks for your questions. With respect to naming conventions, you can implement INamingStrategy to provide custom name resolution. Updateable views can also be used as a level of indirection between LightSpeed and your physical tables. On code generation - We're working on some tools for our v2 release. How did you hear about LightSpeed? Cheers, Andrew. |
|
|
>you can implement INamingStrategy Ok, it's providing methods to override special columns, and what about enity-specific columns? In ORMs I'm using now it's providing by attributes like MapTo["some_name"], Persistent["some_name"], etc. >How did you hear about LightSpeed? Oh... it is hard to remember... probably it was an article on some website with ORM overviews, not sure. |
|
|
[quote user="Svetloyar"]Ok, it's providing methods to override special columns, and what about enity-specific columns? In ORMs I'm using now it's providing by attributes like MapTo["some_name"], Persistent["some_name"], etc.[/quote] As you say there are other ORMs that already work this way. LightSpeed tries to be different by being reasonably opinionated and favoring a convention-over-configuration based approach. As such, LightSpeed is sometimes not the best choice for mapping complex or legacy scenarios. Cheers, Andrew. |
|
|
Imho, advanced mapping support (not requirement!) is not the way in which the LightSpeed must be different, you're already have perfect differents, like a providing of practice patterns methodology, validation rules and lightweight despite of LS functionality! |
|