I make these two calsses and try to express it to UML Class diagram
publc Class A
{
public A(){}
public void Funct1()
{
B b = new B(this);
}
}
public Class B
{
A m_A = null;
public B(A a)
{
m_A = a
}
}
I think class "A" have "Dependency" to B becuase A don't maintain reference to B
And I think class "B" have "one directional Association to A" because class B maintain reference to A.
So, I draw class diagram as follow.
dependency
-------->
[A] [B]
<-
one directioinal association
But, this diagram looks somewhat wrong even to me.
So, I want to know How to express this relation between these classes to class diagram.
No, that seems perfectly valid to me for the reasons you mentioned yourself.
The only thing is that is "somewhat wrong" is the fact that you have a bi-directional dependency between A and B, making the two classes tightly coupled. You should avoid tight coupling whenever possible, but sometimes you don't have much other options.
there is just association needed to define in UML for your example. But, it is not possible to determine what multiplicity is at the B side, multiplicity at A side is 0..1 if there is possible to set null to m_A.
No dependency is necessary to draw in UML in your example. Dependency does not have runt time impact. It is defined between model element definition.
Read UML Superstructure to get precise information about dependency relationship.
Related
I'm trying to get a handle on DI lately.
If I understand everything correctly so far, the main purpose is to write loosely coupled code, to facilitate re-usability.
(Also see https://stackoverflow.com/a/9503612/579740)
So far so good, but one thing that's still not entirely clear to me, is where to place the interfaces.
An example tells more then a thousand words:
Library A:
public class A
{
public A(IInterfaceB b)
{}
}
Library B:
public interface IInterfaceB
{}
public class B : IInterfaceB
{
public B (IInterfaceC c)
{}
}
Library C:
public interface IInterfaceC
{}
public class C : IInterfaceC
{
public C()
{}
}
If I place IInterfaceC in Library C, I still have a reference to Library C in Library B.
So when I decide to reuse library B, I still need Library C???
Which, in my mind at least, doesn't seem to be loosely coupled...
Can someone explain to me where my thinking is going wrong?
Loose coupled code doesn't always mean loose coupled modules (libraries).
You can achieve loose coupling of modules (libraries) by placing interfaces and implementations in different modules. For example class A is in A.dll, IInterfaceB is in IInterfaceB.dll (and A.dll reference it), class B is in B.dll (and it reference IInterfaceB.dll too)
It looks like following
class A -> IInterfaceB <- class B
so modules containing class A and class B are not coupled.
I'm using Entity Framework 5.0 with code-first approach plus inheritance for my business objects represented by Table Per Hierarchy.
I'd like to have the following structure:
//Assembly 'DataAccess'
public class MyDbContext : DbContext
{
DbSet<AbstractClass> CommonObjects.AbstractClasses { get; set; }
}
//Assembly 'CommonObjects'
public abstract class AbstractClass
{
//implementation
}
//Assembly 'DerivedObjects'
public class DerivedClass : AbstractClass
{
//implementation
}
During runtime, when trying to access the DbContext the first time, the compiler throws an InvalidOperationException saying:
The abstract type 'CommonObjects.AbstractClass' has no mapped descendents
and so cannot be mapped. Either remove 'CommonObjects.AbstractClass' from
the model or add one or more types deriving from
'CommonObjects.AbstractClass' to the model.
Is this scenario even possible? If yes, what am I doing wrong?
Thanks for your answers in advance.
Ben
Additional information:
Maybe I should be a bit more specific:
I got one assembly containing my abstract business objects (only abstractions). The concrete implementations (containing the logic) are kept in the responsible assemblies, as their logic depends upon other classes within that assembly. The issue is, I want to be able to store those conrete implementations in the persistance layer as well. But for that purpose, EF had to know those types in order to enable the mapping. But I dont want to make the persistance layer depend on my business logic layer - only the abstractions.
That's why I tried to add the derived objects to the DbContext directly from the Business Object Layer.
Example:
AbstractClass derivedClass = new DerivedClass();
MyDbContext.AbstractClasses.Add(derivedClass);
But then the exception above is being thrown. I just can't figure out a good structure to achieve this.
Do you always create these two abstract base classes as the basis of any new project in DDD?
I've read that Entity should have two things. First, an identity property, probably of a generic type. Second, an Equals() method that determines whether it's the same as another Entity. Anything else? Any other natural methods or rules of thumb?
I like to have a common abstract ancestor for all my Domain objects but that is a matter of preference and overall infrastructure requirements.
After that, yes I have abstract classes for Entity and Value objects.
Don't forget that also overriding Equals for Value objects to return equality based on equal property state can be important.
Also people frequently overlook the value of packages. Put all these core base classes in their own "kernel" library and don't be reluctant to split your domain model into multiple assemblies instead of winding up with a single large "Domain Library".
If you're using .NET/C#, I've published a set of DDD interfaces and classes for public use. Take a look to see what typically goes inside them. The embedded code comments should hint towards their usage.
You can [download it here][1]. Project is dead now.
I've never needed the Equals() method in my applications thus far. Your mileage may vary though.
However, I create empty interfaces and use them as descriptors:
public interface IAggregateRoot {}
public interface IEntity {}
public interface IValueObject {}
public class Order : IAggregateRoot
{
...
}
public class State : IValueObject
{
...
}
I am using Visual Paradigm for UML to model our class hierarchy. I often have the case where one of our interfaces has a method requires an implementation of another of our interfaces as parameter to a method. Example (C++, interface = abstract class):
class IFoo {
public:
virtual void bla() = 0;
};
class IBar {
public:
virtual void meep(IFoo &) = 0;
};
I have no problem modeling both interfaces, but I am wondering which type of association to use for visually representing the relation of these two interfaces. Currently I am using the Usage-relation provided by Visual Paradigm, but I am not sure if this is indeed intended for this scenario. Is this the correct relation to use? If not, how can I model this relationship?
At least in a class diagram there is no visual representation of what's going on.
The Usage that you suggested would make it some kind of "meta" information, I guess. An alternative would be to specify it in a Usecase diagram. But that'd also be what I'd call "out-of-band" or on the meta-level, as Usecases are usually only used to communicate a warm, fluffy feeling of having documented something...
You can use a dependency arrow pointing from the interface with the dependent operation to the interface used as a parameter in the operation. You can then model the specifics of the dependency by providing the full signature of the dependent operations in your interface model element.
If you wanted to provide even more detail describing the nature of the dependency, you could attach a note to the dependency arrow.
Using your example:
I have a Foo entity in Entity Framework. But I'm making it inherit from IFoo so that my business logic only knows IFoo - thus abstracting Entity Framework away.
The problem is that Foo has a collection of Bar entities. And this collection is of type EntityCollection<Bar> .
If I put this collection in IFoo as it is, I make IFoo dependent on Entity Framework. So I thought of putting it as ICollection<IBar>, but this doesn't compile (naturally).
The only solution I can think of is to go to the concrete Foo implementation generated by the Entity Framework designer and change the collection from EntityCollection<Bar> to ICollection<IBar> there. But I dread the thought of the implications this will have on Entity Framework "behind the scenes".
Is there any way for me to define IFoo and IBar independently of Entity Framework while still maintaining Foo and Bar as EF Entities that implement them? Do IFoo and IBar even make sense, if I cannot achieve this independence that I aim for?
The general concept you are referring to is "persistence ignorance" (PI), although that generally applies directly to entities themselves rather than the code that consumes the entities.
In any case, Hibernate and NHibernate natively support PI, but the initial version of Microsoft's Entity Framework does not. MS caught a lot of flak for this and PI is probably the #1 most discussed feature for the next version (whenever that is).
As far as what you are trying to do with interfaces, does the collection of Bars need to be modified after it is retrieved? If the answer is yes, there is no easy answer. Even covariance couldn't help you here because ICollection<T> has an Add method.
If the collection is read-only, then you might consider exposing it as IEnumerable<IBar>. The Enumerable.Cast method makes this fairly convenient.
interface IFoo
{
IEnumerable<IBar> Bars { get; }
}
partial class Foo : IFoo
{
IEnumerable<IBar> IFoo.Bars
{
get { return Bars.Cast<IBar>(); }
}
}
Also, I know of at least one effort to make the current version of EF support persistence ignorance.
I'm a Java developer, so I can't comment with any authority on Entity Framework. I can tell you that ORM solutions like Hibernate make it possible to have POJO persistence without having to resort to common abstract classes, interfaces, or modifying byte code. It handles relationships like the 1:m you cite for your Foo and Bar without having to use special collection classes.
The special sauce is externalized into mapping configuration and Hibernate itself.
The little bit that I read about Entity Framework suggests that it's an ORM solution with the same aim: POCO persistence. I didn't see any mention of interfaces. I can't see the need for them from your example, because it's too abstract.
I'm inferring that it's possible to get that independence between business objects and persistence tier without having to resort to those interfaces, because I know Hibernate does it. I'd say that Spring's JDBC solution accomplishes it as well, because there's no need for common interfaces. They use a RowMapper construct to ferry data out of a query and into an object.
I wish I could advise you precisely how to do it with Entity Framework, but maybe you'll take heart knowing that it can be done.
I recently wrote a comprehensive post about this: Persistence Ignorance in ADO.NET Entity Framework. You might want to look at EFPocoAdapter. That does just this and it will eventually deprecate into EF v2.
For what it's worth, I am using EFPocoAdapater and it's been working well for me.
We've been doing the exact same thing for LINQ to SQL. I got around the collection issue by writing a class which wraps an IList and casts to and from the correct type as required. It looks a bit like this:
public class ListWrapper<TSource, TTarget> : IList<TTarget>
where TTarget : class
where TSource : class, TTarget
{
private IList<TSource> internalList;
public ListWrapper(IList<TSource> internalList)
{
this.internalList = internalList;
}
public void Add(TTarget item)
{
internalList.Add((TSource)item);
}
public IEnumerator<TTarget> GetEnumerator()
{
return new EnumeratorWrapper<TSource, TTarget>(internalList.GetEnumerator());
}
// and all the other IList members
}
EnumeratorWrapper similarly wraps an IEnumerator and performs the casting.
In the LINQ to SQL partial classes we expose the property like this:
public IList<ICustomer> Foos
{
get
{
return new ListWrapper<Foo, IFoo>(this.Foos_internal);
}
}
Any changes to the exposed list will be performed on the internal EntitySet so they stay in sync.
This works well enough but my feeling is that this whole approach is more trouble than it's worth, I'm a huge NHibernate fan and a strong believer in P.I. but we've put in a LOT of extra effort doing this and haven't really seen any advantage. We use the repository pattern to abstract away the actual DataContext access which I would say is the key part of decoupling ourselves from LINQ to SQL.
Use a partial class to seperate your logic and rules from the autogenerated EF objects. In the example below FooEntityObject class is split into two using the partial keyword. I've used this technique before with EF and LINQ to SQL. The partial classes can be stored in seperate files so if your regenerate your EF object again your custom code doesn't get overwriten.
interface IFoo
{
public ICollection<IBar> GetBars();
}
public partial class FooEntityObject : IFoo
{
public ICollection<IBar> GetBars()
{
// convert EntityCollection<Bar> into ICollection<IBar> here
}
}
public partial class FooEntityObject
{
EntityCollection<Bar> Bars{get;set;}
}