Is it possible to do inheritance with NHibernates component? A quick google returned only a hand full of appropriate results (all blogs) and all were written some time ago so was wondering if it is available yet?
if not how do you handle it instead?
It's not currently possible. If you need inheritance, you have to map an entity.
In addition to what Diego had said, there is also an option to implement custom hydration/dehydration for hierarchy using IUserType. See this article for details (its Java but the same mechanism can be used in C#).
And Hibernate feature request is here. NHibernate version is here, please vote.
Yes.
public class A { }
public class B : A { }
public sealed class C : B { }
public abstract class BaseAMap<T> : ComponentMap<T> where T : A {
public BaseAMap() {
// Map A here
}
}
public class AMap : BaseAMap<A> {
}
public class BaseBMap<T> : BaseAMap<T> where T : B {
public BaseBMap () {
// Map B (excluding A)
}
}
public class BMap : BaseBMap<B> {
}
public sealed class CMap : BaseBMap<B> {
public CMap () {
// Map C (excluding B)
}
}
Related
I am having some problems mapping the following scenario in Fluent Nhibernate using Table Per Concrete class:
Let's say I have the following class definitions:
public class Reading { .... }
public class CarReading : Reading { .... }
public class TruckReading : Reading { .... }
public class Alert
{
....
public virtual Reading AReading { get; set; }
}
So my question is how to create the mapping class for Alert, if it has a one to one relationship with reading class (could be either truck reading or car reading) and instruct nhibernate to know which table to load the data from (TruckReading table or CarReading Table)
public class AlertMap : ClassMap<Alert>
{
....
HasOne(x => x.AReading);
}
If anyone could point me in the right direction that would be much appreciated.
Thanks.
public class AlertMap : ClassMap<Alert>
{
....
ReferenceAny(x => x.AReading)
.EntityIdentifierColumn("readingid")
.EntityTypeColumn("readingtype")
.IdentityType<int>()
.AddMetaValue<CarReading>("car")
.AddMetaValue<TruckReading>("truck");
}
I have 2 classes that have the exact same logic/workflow, except in one method.
So, I created a abstract base class where the method that differs is declared as abstract.
Below is some sample code to demonstrate my design; can anyone offer suggestions on a better approach or am I heading in the right direction.
I didn't use an interface because both derived classes B and C literally share most of the logic. Is there a better way to do what I am doing below via dependency injection?
public abstract class A
{
public void StageData()
{
// some logic
DoSomething();
}
public void TransformData();
public abstract DoSomething();
}
public class B : A
{
public override void DoSomething()
{
// Do Something!
}
}
public class C : A
{
public override void DoSomething()
{
// Do Something!
}
}
There is nothing wrong with what you have done. To introduce dependency injection into this design would be messy and overkill - you would have to pass in a delegate:
public class ABC
{
public ABC(Action z)
{
_doSomethingAction = z;
}
public void DoSomething()
{
_doSomthingAction.Invoke();
}
private Action _doSomthingAction;
}
There would be few reasons why you want to use this approach - one would be if you needed to execute a callback. So stick with the pattern you have, don't try to overcomplicate things.
I have an object: X, that can be saved or loaded in various formats: TXT, PDF, HTML, etc..
What is the best way to manage this situation? Add a pair of method to X for each format, create a new Class for each format, or exists (as I trust) a better solution?
I'd choose the strategy pattern. For example:
interface XStartegy {
X load();
void save(X x);
}
class TxtStrategy implements XStartegy {
//...implementation...
}
class PdfStrategy implements XStartegy {
//...implementation...
}
class HtmlStrategy implements XStartegy {
//...implementation...
}
class XContext {
private XStartegy strategy;
public XContext(XStartegy strategy) {
this.strategy = strategy;
}
public X load() {
return strategy.load();
}
public void save(X x) {
strategy.save(x);
}
}
I agree with #DarthVader , though in Java you'd better write
public class XDocument implements IDocument { ...
You could also use an abstract class, if much behavior is common to the documents, and in the common methods of base class call an abstract save(), which is only implemented in the subclasses.
I would go with Factory pattern. It looks like you can use inheritance/polymorphism with generics. You can even do dependency injection if you go with the similar design as follows.
public interface IDocument
{
void Save();
}
public class Document : IDocument
{
}
public class PdfDocument: IDocument
{
public void Save(){//...}
}
public class TxtDocument: IDocument
{
public void Save(){//...}
}
public class HtmlDocument : IDocument
{
public void Save(){//...}
}
then in another class you can do this:
public void SaveDocument(T document) where T : IDocument
{
document.save();
}
It depends on your objects, but it is possible, that visitor pattern (http://en.wikipedia.org/wiki/Visitor_pattern) can be used here.
There are different visitors (PDFVisitor, HHTMLVisitor etc) that knows how to serialize parts of your objects that they visit.
I would instead suggest the Strategy pattern. You're always saving and restoring, the only difference is how you do it (your strategy). So you have save() and restore() methods that defer to various FormatStrategy objects you can plug and play with at run time.
I have a class, say Provider, that exposes its funcationality to the above service layers of the system. It has a public method, say GetX(). Now, there are two ways to get the X : XML way and non-XML way. Two "Library" classes implement these two ways, one for each.
Thus, the structure that happens is something as follows :
public class Provider
{
private XmlLib _xmlLib;
private NonXmlLib _nonXmlLib;
public X GetX( // parameters )
{
// validate the parameters
if ( // some condition)
X = _xmlLib.GetX();
else
X = _nonXmlLib.GetX();
return X;
}
// several other such methods
}
internal class XmlLib
{
public X GetX()
{
// Xml way to get X.
}
// several such things to get/send in XML way.
}
internal class NonXmlLib
{
public X GetX()
{
// NonXml way to get X.
}
// several such methods to get/send thing in non-XML way.
}
So its like, the Provider class becomes a sort of a dumb wrapper, which only validates the arguments, and based on one condition, decides which lib to call.
Is this a good implementation? Any better way to implement this?
Let the GetX method be in an interface. from that point on you can have as many classes that you want that implement the interface.
public interface ISomeInterface { X GetX(); }
Now build a class that will implement the factory design pattern (read about it if you do not know it) and let this class accept the condition which will enable it to decide which class that implements the above interface to return.
here's what I said through code:
public class XmlWay : ISomeInterface
{
public X GetX()
{
//your implementation
}
}
public class NonXmlWay : ISomeInterface
{
public X GetX()
{
// Another implementation
}
}
and finally the factory class
public class MyXFactory
{
public static ISomeInterface GetXImplementation(bool someCondition)
{
if (someCondition)
return new XmlWay();
else
return new NonXmlWay();
}
Now see how elegent your code will look:
ISomeInterface xGen = MyXFactory.GetXImplementation(true);
xGen.GetX();
Hope this helps.
Is it possible to create a simple convention to modify the polymorphism mode of a class, if there is a joined-subclass ?
Doing this :
public class EntityMap : ClassMap<EntityBase>
{
public EntityMap()
{
Polymorphism.Explicit();
}
}
but inside a convention. Using IClassConvention doesn't work, as the Polymorphism property is read only :
public class TestConvention : IClassConvention
{
public void Apply(IClassInstance instance)
{
// read only property !
instance.Polymorphism = Polymorphism.Explicit;
}
}
Try
instance.Polymorphism.Explicit();