Hi,
i want to implement some embedded ValueObjects for my BusinessObject. For example: I want to implement a money class with the properties "Quntity" and "Currency" and some useful methods for rounding, CurrencyConvert, Adding amounts.... . How should I implement this ? Is it a Csla.NET Child Object or somthing like a SmartDate ?
Regards
Josef
First, you should decide if you want to ever support Silverlight or WP7. If you do, you'll need to implement IMobileObject or use one of the existing serializable base classes. CSLA includes some low-level base classes in Csla.Core for reference types, but a struct can't inherit base class behavior, so any struct will need to implement the interface directly.
Second, you need to decide what semantics you want. Reference types and value types are different, and they work differently in code. SmartDate is a value type (struct) because I am emulating DateTime, which is a value type. That has its good and bad points, but clearly makes sense for my particular scenario.
While there are sometimes some minor differences in how .NET stores ref and value types in memory, for the most part there's not any realistic difference in terms of memory or performance. So the real criteria here is how you want fields of this type to act - like a reference type or a value type.
So make that decision and roll with it :)
Thanks for the answer. I have one last question to this point. I have make the decision to implement my Money Object with value semantic ( immutable object, copy by value). Know it is possible to implement the Money Object as a struct like the SmartDate. Ich think it is also possible to implement it as an immutable Reference Type (like the .net String Implementation). This means, the implementation shoult return new Money Instances for methods witch changes the state of a Money Object. Do you have any suggestions in the context of csla how to implement value smenatic ( struct or immutable reference type). The Microsoft Framework Design Guidelines recommends the following:
"Consider defining a struct instead of a class if instances of the type ars small and commonly short-lived or are commany embedded in ohter object .
Do not define a struct unless the type has all of the following characteristics:
1. It logically represents a single value, similiar to primitive type(int, double, ect.)
2. It has an instance size under 16 bytes.
3. It is immutable.
4. It will not have to boxed frequently
In all other cases, you should define your types as classes "
Expect the 16 byte constraint my Money Object has all of this characteristics. I am not shure if this characteristics are hard rules or more a rule of thumb.
Regards
Josef
Copyright (c) Marimer LLC