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
|
Hi, Our group is looking for a ORM solution. So far Lightspeed looks flexible and very promising because, unlike MS EF, allowes mapping of DB to logical model, not only physical. We already have an extensive class model presented in UML and mapping information presented in our own tool. In addition we have possibility to generate any code using such information. But it looks the only way to generate Lighspeed classes is a generation of C# code wich usually is done by Lightspeed designer. We can do it implementing generator template, but it looks little akward - changes in Lightspeed interface can force us to modify a template. For me it looks more reasonable to have some intemediate format, let say like SSDL/CSDL/MSDL which can be used to generate Lightspeed classes. May be you already have such possibility. So shortly the question is - what is a recommended way to import already existing class model and mapping information? Thank you, |
|
|
|
|
You are right, LightSpeed classes are implemented as C# (or VB) code, and this is normally generated by the LightSpeed designer. However there's no requirement to have the designer involved -- many customers hand-code their classes, and the interfaces and classes are fully documented and supported. So if your UML tool supports a templating system similar to T4 or NVelocity then that would be the most direct approach. You would of course need to create that template but that would be a one-off cost, and you could probably include the NVelocity templates that are part of the designer as a starting point. If you do prefer to go via an intermediate format, the closest we have is the .lsmodel file format used by the designer. This is a fairly simple XML format. It is not documented, but it is pretty stable and usually we only add things rather than changing things. However, if you decide to generate a .lsmodel from your UML tool, you will still need to generate C# classes from the .lsmodel. This can be done interactively using Run Custom Tool in Visual Studio, but if you want to automate the process you can also use the lsgen.exe command line tool -- this is mainly used for generating LightSpeed classes from a database a la sqlmetal, but it can also be used to generate classes from .lsmodel as part of a batch process. As for a recommendation, it really depends on the relative complexity in your UML tool of outputting C# code versus outputting XML and running a post-processing step on that XML. If XML is much easier then I would go via the .lsmodel format; otherwise I would just go straight to C# and cut out the middleman. (I am assuming here that you intend to keep your UML diagrams as the master, re-importing whenever you update the UML. If the import is a one-off and you will subsequently be maintaining the model in LightSpeed, then I would definitely go for the .lsmodel.) |
|
|
|
|
Yes, I overlooked the .lsmodel file. Simple and obviouse structure. Template was very easy to create. Now our old class models and mappings are available for .Net development! Thank you so much! |
|
|
|
