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
|
I'm curious about a few of the things that LightSpeed requires me to do with my model classes. Im just looking for a little explanation as to why these things
Thanks for any explanation as to the reasoning behind this.
Jesse
|
|
|
[quote user="jnapier"]Foreign key fields are required - I would think that the foreign key could be determined from the EntityHolder. I dont like having to define foreign keys in my model classes, seems like it muddies up the model with relational data.[/quote] Good question. A couple of reasons: Simplicity is one. You will have noticed quite a few places in the framework where we're trading off against a pure PI approach. This is principally done to keep things simple, small and fast. Another reason is that the foreign key field tells us something important about the underlying schema - in particular whether it's int? or int :-) [quote user="jnapier"]Public default constructors are required - Sometimes I want to use a factory for newing an object and having to put public default constructors on my classes indicates that the class can be directly instantiated to those using the API.[/quote] Primarily because LightSpeed needs to be able to create new instances of the object. We could support a user supplied factory approach without too much effort I think. Cheers for the feedback. |
|
|
I get you on the simplicity. LightSpeed is super easy to use. The problem is, you guys have done some great work here and I want it to push it to the next level and use it on more complex domains. One thing that is really starting to to bug me is that all associations have to be bidirectional. There are just sometimes that you really really don't want a bidirectional association. For example im working on this one sample, Accounts can select a favorite VideoGame. I really dont want to have a collection of accounts in my VideoGame class. How bad is this for performance if I never use the videoGame.AccountsWithFavorite colelction? Any plans on making a more full featured domain modeling version? |
|
|
[quote user="jnapier"]One thing that is really starting to to bug me is that all associations have to be bidirectional. There are just sometimes that you really really don't want a bidirectional association. For example im working on this one sample, Accounts can select a favorite VideoGame. I really dont want to have a collection of accounts in my VideoGame class. How bad is this for performance if I never use the videoGame.AccountsWithFavorite colelction?[/quote] There is no performance overhead because the collection won't be loaded unless you access it. However, for the situation you outline we may be able to remove the requirement to have to collection at the other end - I'll take a look. [quote user="jnapier"]Any plans on making a more full featured domain modeling version?[/quote] Not at this stage as there are already quite a few of those :-) |
|