DC: One-to-many relationship

EDIT:
Domain Components (DC) is in maintenance mode and we do not recommend its use in new software projects.

In the first post of the series devoted to our new domain component (DC) technology, I tried to show an interface-defined entity in a UI.

I used some IPerson component as an example:

	public enum Gender { Unknown, Male, Female }

	public interface IPerson {
		string FirstName { get; set; }
		string MiddleName { get; set; }
		string LastName { get; set; }
		string FullName { get; }
		DateTime Birthday { get; set; }
		Gender Gender { get; set; }
	}
	[DomainLogic(typeof(IPerson))]
	public class PersonLogic {
		public static string Get_FullName(IPerson self) {
			return self.FirstName + " " + self.LastName;
		}
	}

IPerson is a library interface that will be used as an entity rarely. In a real-world application, another entity is expected. For instance, it may be a Developer, the entity that implements the IPerson interface, in addition to other interfaces. Assume the Developer contains Notes. So, we add the INote and IItemWithNotes library interfaces:

	public interface IItemWithNotes {
		IList<INote> Notes { get; }
	}

	public interface INote {
		string Text { get; set; }
		IItemWithNotes Owner { get; set; }
	}

Combining these two interfaces, we get the IDeveloper interface:

	public interface IDeveloper : IPerson, IItemWithNotes{ 
	}

I change the entity registration code, which I showed in the previous post, to the following:

		public override void Setup(XafApplication application) {
			XafTypesInfo.Instance.AddEntityToGenerate("Developer", typeof(IDeveloper));
			XafTypesInfo.Instance.GenerateEntities();
			base.Setup(application);
		}

If I run my application now, it won't work. The problem is that I should map the INote interface to a real entity. Here, I have a design challenge: should XAF generate other entities for the Developer entity, or should it require that all Developer-related entities are registered manually? Currently, I think it is better to make a developer responsible for registering entities. First, it will give him direct control on what happens in the physical database. Second, our automatic logic can be wrong. So, I change the entity registration code again:

		public override void Setup(XafApplication application) {
			XafTypesInfo.Instance.AddEntityToGenerate("Developer", typeof(IDeveloper));
			XafTypesInfo.Instance.AddEntityToGenerate("Note", typeof(INote));
			XafTypesInfo.Instance.GenerateEntities();
			base.Setup(application);
		}

After I made these changes, my application works:

Note that the FullName property is calculated properly. Remember that we declared this property with a getter only. However, we implemented the PersonLogic class that contains the Get_FullName method. When the XpoBuilder generated the implementation of the Developer object, it uses the Get_FullName method to generate the FullName property.

As you can see in the screenshot above, the "Link" and "Unlink" Actions are available (they are circled). This means that the system thinks that a Note object can be created independently. I need a way to tell the XpoBuilder that the IItemWithNotes.Notes is an aggregated collection. I want to be able to write this:

	public interface IItemWithNotes {
		[Aggregated]
		IList<INote> Notes { get; }
	}

I still can't do that. So, I've written a test that shows what I need, and now I’m waiting for the Xpo team. I'll focus on other problems with associations. Stay tuned.

Free DevExpress Products - Get Your Copy Today