Is there any way to get the name of a relationship given the from and to entities?
I have a fairly dynamic piece of code that needs to Associate or Disassociate entities. In order to call these functions, I need to know the name of the relationship. I am not sure how to determine the relationship name just given the two entities.
For example, my code might need to disassociate an account with a contact. How can I determine the relationship name of "account_primary_contact"?
In the interest of answering the question despite my not understanding why you would want to do this:
foreach (OneToManyRelationshipMetadata relationshipMetaData in primaryEntityMetadata.ManyToOneRelationships)
{
if (relationshipMetaData.ReferencingEntity == relatedEntity.LogicalName)
{
string relationshipName = relationshipMetaData.SchemaName;
//Do something with your relationship?
}
}
Where primaryEntityMetadata is of type EntityMetadata and ReferencingEntity is of type Entity. Then use similar logic for checking Many to One relationships.
Related
I am currently trying out DDD and reading Evans book. I have arrived at a model that has an aggregate whose root is Student. Now I need to have (or be able to distinguish) a RegisteredStudent and an EnrolledStudent (inherits RegisteredStudent). I don't know how to handle inheritance in DDD.
Should the 2 inherited classes be inside the aggregate? If so, are they also considered aggregate roots since their identity is the same as the root (there are only added properties to them)? If not, how do I give access to them from other entities?
Or should I not be using inheritance? Why?
And also, what if you have an entity in an aggregate that isn't a root, but you need it to inherit an entity outside? How should you go about it?
What you need to ask yourself here is whether a RegisteredStudent and an EnrolledStudent are different concepts. Are they not both students, but just in a different state?
In general, you should favor composition over inheritance.
Here's an example of what I would do. (Note that it's just my example, I don't know the domain, so it's not a definitive solution).
You could have a Student class, which is your aggregate root and then a few different state classes: Registered and Enrolled. That way you don't need to expose these state classes on the student but you could just expose methods on the Student. A small example in C#:
class Student
{
State _currentState;
void Enroll()
{
if(!_currentState is Registered)
throw new InvalidOperationException("Cannot enroll student who is not registered");
this._currentState = new Enrolled();
}
void Register(string name)
{
this._currentState = new Registered(name);
}
}
class StudentState{}
class Enrolled : StudentState
{}
class Registered : StudentState
{
public Registered(string name)
{
Name = name;
}
public string Name {get; private set;}
}
This is a simple application of the State design pattern, you could externalize more parts of it and build a complete state-machine, but I'll leave that up to you. (Also it's typed directly in to the SO-editor, so there could be syntax errors)
EDIT after comments
Whether you need to expose a State-property or not depends on the context. In general I would recommend not to do that, because you're exposing the internals of the Student. It would be better to expose a method called CanEnroll for example. That way you can change the internal implementation of your state pattern without affecting any clients.
As for question 3, it's hard to say without a use case. However, here are some guidelines:
Favor composition over inheritance (again, I know).
You can have a reference from inside an aggregate to the outer world, you shouldn't have a reference the other way around though.
Assume I have the relationship where every customer has an address (which in this case, is an entity), like below:
Customer{ Id, Name, MyAddress (instance of Address) }
Should I be allowing a structure that exposes the following option:
MyCustomer.MyAddress.Street = "Pine Street";
CustomerRepository.Save(MyCustomer);
Should this cascade a save, both for the Customer class and for the Address class? Or, is it better to perform the following:
MyCustomer.MyAddress.Street = "Pine Street";
AddressRepository.Save(MyCustomer.MyAddress);
Unfortunately, Address really is a value object, but I cannot make it interchangable like DDD requires as the Id tag is present; for example, if I did the following:
Customer1.setAddress(Customer2.getAddress());
Both Customer1 and Customer2 now have the same binding to the same record, which is dangerous.
None of your samples is DDD. Each one is simple CRUD.
Don't "set fields". Do meaningful operations.
customer.MoveTo(new Address(...))
customer.FixAddressTypo(new Address(...))
Repositories are for aggregates, not any entities. Identify your aggregates. http://dddcommunity.org/library/vernon_2011/
Why not map the Addres value Object as a bunch of fields in the Cutomers table? You don't need separate table just because you have a separate class.
Value objects should be immutable.
I'm developing an application with Domain Drive Design approach. in a special case I have to retrieve the list of value objects of an aggregate and present them. to do that I've created a read only repository like this:
public interface IBlogTagReadOnlyRepository : IReadOnlyRepository<BlogTag, string>
{
IEnumerable<BlogTag> GetAllBlogTagsQuery(string tagName);
}
BlogTag is a value object in Blog aggregate, now it works fine but when I think about this way of handling and the future of the project, my concerns grow! it's not a good idea to create a separate read only repository for every value object included in those cases, is it?
anybody knows a better solution?
You should not keep value objects in their own repository since only aggregate roots belong there. Instead you should review your domain model carefully.
If you need to keep track of value objects spanning multiple aggregates, then maybe they belong to another aggregate (e.g. a tag cloud) that could even serve as sort of a factory for the tags.
This doesn't mean you don't need a BlogTag value object in your Blog aggregate. A value object in one aggregate could be an entity in another or even an aggregate root by itself.
Maybe you should take a look at this question. It addresses a similar problem.
I think you just need a query service as this method serves the user interface, it's just for presentation (reporting), do something like..
public IEnumerable<BlogTagViewModel> GetDistinctListOfBlogTagsForPublishedPosts()
{
var tags = new List<BlogTagViewModel>();
// Go to database and run query
// transform to collection of BlogTagViewModel
return tags;
}
This code would be at the application layer level not the domain layer.
And notice the language I use in the method name, it makes it a bit more explicit and tells people using the query exactly what the method does (if this is your intent - I am guessing a little, but hopefully you get what I mean).
Cheers
Scott
I have a complex scenario that I'm trying to model using Orchard CMS parts.
Now here it is the simplified version to make clear my question.
I have a part name, as example, PersonPart that has just one property: Name.
I have another part that contains the person role, name it PersonRolePart and has just one property, Role
In Orchard I have created all the appropriate plumbing (Handlers, Drivers, Views...)
In migrations I created a new content type named Person that contains the two parts.
ContentDefinitionManager.AlterTypeDefinition("Person", cfg => cfg
.WithPart("PersonPart")
.WithPart("PersonRolePart")
.WithPart("CommonPart")
.Creatable(false) );
So far so good, I can create a new person and edit both parts.
Another part that I have is a ServicePart that is bound to one of the PersonRoleParts defined above.
Now the question:
For reporting purpose I need to get all services by PersonRole and get the person details that belong to that role or, in other words, get all the (only one indeed) PersonPart that is used in the Person compound type defined above.
How to do that?
Now in a non-orchard world I would create a simple 1:1 relationship between the 2.
My (failed) attempt so far was to add a PersonRoleRecord_Id field to PersonPartRecord and a PersonRecord_Id to Person role... but I have no idea how to set to correct id on driver or handler since both see just the own part.
Is it possible from driver get an instance of the other fellows parts in content type?
Merge Person and Role is not possible. The scenario is more complex than that and I need same Person Part an 3 different Role-like part for different purposes and I want to avoid duplicate common person data 3 times.
Another idea was to create an appropriate handler but I do not know how to create an Handler for a virtual content type like the one I did.
I have managed to solve using the advice on another question that addressed a different problem (validation).
Orchard CMS - determining if Model is valid in Content Item Driver
So my solution was to add an handler to both and cast the part and set the appropriate reference to the other part.
OnPublishing<PersonPart>((context, part) =>{
var person = part.As<PersonPart>();
var role= part.As<PersonRolePart>();
if (person != null && role != null) {
if (role.Person == null) {
role.Person = person.Record;
}
}
});
In this specific case since it is a 1:1 relation so i I use just that combined part, both id are the same, at least if the role is just of one type.
I will see when I will create more role-like parts.
I am trying to do exactly same thing as post in NSFetchResultsController + sectionNameKeyPath + section order, i.e. basically use 2 tables, let's say Categories <-->> Events. Category table consists of category field only, while Event consists of name, dateTimestamp.
I defined relationship 'category' in Events table and try to use that relationship as sectionNameKeyPath when creating fetchedResultsController:
NSFetchedResultsController *aFetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:self.managedObjectContext sectionNameKeyPath:#"category.category" cacheName:#"Root"];
Finally, I pre-populated Category table with some categories upon loading of the app (and verified with .dump that table is populated correctly)
Yet, I simulator fails on:
return [[self.fetchedResultsController sections] count];
I did extensive search and most people either suggest using one of the fields in the table as sectionNameKeyPath (this works!) or transient property (works too!) However, I just want to use relationship as it seems very logical to me in this case where events belong to some categories and there could be categories without events. Am I wrong in my assumption that relationship can be used as sectionNameKeyPath? The original link at the top of the question suggests it works, but guy does not know why or how. Documentation is very weak on what can be used as sectionNameKeyPath, so any help will be highly appreciated.
A relationship gets you a pointer to a managed object. It seems logical, though, that the sectionNameKeyPath parameter should be a key path that leads to a string, since NSFetchedResultsSectionInfo's name property is a string. The fetched results controller will follow that key path for each fetched object and group the objects into sections based on what they return for that key path, and it'll also use those strings as the names of their respective sections. You can't use a managed object for the name -- you have to use some string property of the managed object.
So, your Category entity must have an attribute that distinguishes one category from another, right? Use that as the key path and (as you've seen) everything will work out.
BTW, I think it's useful to try to get out of the database (rows/fields) mindset and try to think in object-oriented terms like entity and attribute. A big selling point of Core Data is that it provides an abstraction layer that hides the storage mechanism. Thinking in terms of tables is like thinking about blocks and sectors when you're reading or writing a file.
Caleb, thank you for your answer. I do believe my understanding was wrong to some degree. What I had was an entity Category and entity Event. Category has a string field 'category', thus 'category.category' path (first 'category' is relationship in the Event entity)
What I did not take in account, though, is that if there are no events, fetchresultscontroller cannot fetch anything (similar to 'left join')
What I wanted is to show categories even if there are no events. Relationship 'category' will not return anything in this case as there is nothing to return/sort/categorize.
What I had to do (wrong or right - not sure yet) is to treat [managed] object created from Category entity as a separate object in case there are no events and place in the table. When there is one event per category, I can switch to the original method of [automatic] showing events sorted by categories.
This is interesting issue of starting point (empty entities with relationships) where I feel core data is more confusing than traditional relationship database. I also believe that's why all books/articles/reports carefully stay away from this topic. In other words, I could not find analog of "left join" in core data. May be I am wrong because I am relatively new to all this. Below is the description of the entities:
Category <-->> Event
Category - parent
Category.category - attribute of type String
Category.event - relationship to Event entity
Event - child
Event.name - attribute of type String
Event.category - relationship to Category entity
Each event belongs to one category. Category may have multiple events.
Categories should be shown even if there are no events for this category.
I was trying to put Events under fetchresultscontroller. May be I should switch to Category first and then calculate cell based on category.event relationship, not the other way around - did not try that yet.