eXpress App Framework Team

XCRM: Activities

Roman Eremin — Thu, 09 Oct 2008 08:46:00 GMT

This post is one in a series about our work on Domain Components (DC) framework and related component libraries. I’m just describing what we are working on, what problems we are facing and what results we've got so far.

This post is entirely devoted to Activities. It's more interesting to design Activities, because they are more complex than other components that I described earlier. There are three points I consider when designing Activities:

There can be many Activity types: a phone call, email, meeting/appointment, task, campaign activity or case/service activity.
An Activity has an owner - a person who is assigned to perform the Activity. The person should be able to see all his/her activities in one list.
An Activity can be related to a Contact, Account, Lead, Opportunity, MarketingCampaign or any other “main” entity record in the system.

Let's go through all these points:

1. We can divide all Activities into two basic categories:

Event

An Activity that has clear start and end points. Generally, Events can be scheduled on a calendar. So, the system should be able to show all Events in one Calendar view.

Task

A less time-bound Activity than the Event. It may have a DueDate only.

Simple CRM systems work with Tasks and Events simultaneously. More complex systems distinguish these Activity types, so they can track specialized information, like a phone number for a call.

In our application, let’s define a Task and Event. In addition, let's create specialized Activities: a Phone Call, as a variation of the Task Activity, and an Appointment, as a variation of the Event Activity. Here are the tests that express these requirements:

[Test]
public void ActivityTypesTest() {
    ICall call = ObjectSpace.CreateObject<ICall>();
    IAppointment appointment = ObjectSpace.CreateObject<IAppointment>();
    ITask task = ObjectSpace.CreateObject<ITask>();
    IEvent eventObj = ObjectSpace.CreateObject<IEvent>();

    IList<IActivity> allActivities = ObjectSpace.GetObjects<IActivity>(null);
    Assert.AreEqual(4, allActivities.Count);
    IList<IEvent> allEvents = ObjectSpace.GetObjects<IEvent>(null);
    Assert.AreEqual(2, allEvents.Count);
}

[DomainComponent]
public interface IActivity {
    string Subject { get; set; }
    …
    IActivityTarget RelatedTo { get; set; }
}

[DomainComponent]
public interface IEvent : IActivity {
    DateTime StartTime { get; set; }
    DateTime EndTime { get; set; }
    bool AllDayEvent { get; set; }
}

public enum TaskPriority { Low, Medium, High }

[DomainComponent]
public interface ITask : IActivity {
    TaskPriority Priority { get; set; }
    DateTime DueDate { get; set; }
}

[DomainComponent]
public interface ICall : ITask {
}

[DomainComponent]
public interface IAppointment : IEvent {
}

I don’t call the RegisterDC method in this test, because I've moved all Activity registrations to the SetUp method (it is called before a test is started by NUnit):

[SetUp]
public override void SetUp() {
    base.SetUp();
    RegisterDC<ILead>();
    RegisterDC<ICampaign>();
    RegisterDC<IContact>();
    RegisterDC<IAccount>();
    RegisterDC<IOpportunity>();
    RegisterDC<IEvent>();
    RegisterDC<IAppointment>();
    RegisterDC<ITask>();
    RegisterDC<ICall>();
    Generate();
}

Note that I don't register the IActivity. This is a base abstract interface that cannot be instantiated in our system.

2. An Activity has an owner – usually the system's user. The owner may have a list of Activities:

[DomainComponent]
public interface ITestUser : IActivityOwner {
}

[TestFixture]
public class ActivityTests : BaseTest {
    …
    [Test]
    public void ActivityOwnershipTest() {
        ITask blogAboutDC = ObjectSpace.CreateObject<ITask>();
        ITestUser romanEremin = ObjectSpace.CreateObject<ITestUser>();
        blogAboutDC.Owner = romanEremin;
        Assert.AreEqual(blogAboutDC, romanEremin.Activities[0]);
    }
}

[DomainComponent]
public interface IActivityOwner {
    IList<IActivity> Activities { get; }
}

[DomainComponent]
public interface IActivity {
    …
    IActivityOwner Owner { get; set; }
}

3. An Activity can be related to a Contact, Account and any other “main” record in the system. Some systems allow you to link Activities to several records of different type, but I guess this is just a workaround to make programming easier. Our DC framework should be flexible, so I will design it in “the right way”:

[Test]
public void ActivityRelationTest() {
    IAccount account = ObjectSpace.CreateObject<IAccount>();
    IContact contact = ObjectSpace.CreateObject<IContact>();
    ILead lead = ObjectSpace.CreateObject<ILead>();
    IOpportunity opportunity = ObjectSpace.CreateObject<IOpportunity>();
    ITask task = ObjectSpace.CreateObject<ITask>();

    task.RelatedTo = account as IActivityTarget;
    Assert.IsNotNull(account.Activities);
    Assert.AreEqual(task, account.Activities[0]);
    task.RelatedTo = contact as IActivityTarget;
    Assert.AreEqual(task, contact.Activities[0]);
    task.RelatedTo = lead as IActivityTarget;
    Assert.AreEqual(task, lead.Activities[0]);
    task.RelatedTo = opportunity as IActivityTarget;
    Assert.AreEqual(task, opportunity.Activities[0]);
}

To make this test pass, I should define the IActivityTarget interface. Only the components that implement this interface will be able to be added to the “related to” list:

[DomainComponent]
public interface IActivityTarget {
    IList<IActivity> Activities { get; }
}

[DomainComponent]
public interface IActivity {
    …
    IActivityTarget RelatedTo { get; set; }
}

Note that I have not declared a requirement that I want to be able to see all Activity Targets in one list. In that instance, we would have to create a common table for them somehow, and this might be a major restriction on possible use cases of Activities.

I don’t require all IActivityTarget implementers to be in one list, but I still need to be able to edit the RelatedTo field in a UI. This editor should let end-users locate an object of one of predefined types. CRM systems tend to achieve this by adding a combo box with object types. In this instance, end-users first select the type, and then the object of this type:

As far as I know, we don’t have an editor of this kind yet. So, I've written down a task to implement this editor and added a test that describes this scenario. To tell you the truth, the XpoBuilder has trouble with this test. Let me explain in more detail.

How to persist a reference to the interface that is implemented in several classes.

Here, we have a case of leaky abstraction, impedance mismatch and that sort of thing. The fact is that a relational database is not mapped to the OO world easily. In our case – how would you manually implement the scenario where an Activity can be related to one of several records, say, Account or Contact? I see two ways (note that we exclude the requirement that the Contact and Account must have the same base).

The first approach - Multiple associations.

Make two associations:

The implementation of the IActivity.RelatedTo property will look like this:

public IActivityTarget RelatedTo {
    get {
        if (Contact != null) return Contact;
        if (Account != null) return Account;
        return null;
    }
    set {
        Contact = null;
        if (value is Contact) {
            Contact = value as Contact;
            Account = null;
            return;
        }
        if (value is Account) {
            Contact = null;
            Account = value as Account;
            return;
        }
    }
}

This code is ugly, but other than that it looks fine – the Contact and Account have a list of Activities. An Activity allows you to access a Contact or Account as IActivityTarget. But let’s make a simple change. Let's add the Active property to the IActivityTarget interface:

public interface IActivityTarget {
    IList<IActivity> Activities { get; }
    bool Active { get; set; }
}

XPO will not be able to apply a criteria “[RelatedTo.Active] = true” to Activities on the server, because the RelatedTo is not an FK field and cannot be used in a simple SQL query.

The second approach - Intermediate table.

Create an intermediate table for the IActivityTarget interface:

In this instance, the implementation of the IActivityTarget interface in the Account and Contact would redirect all calls to the aggregated ActivityTarget class:

public IList<IActivity> Activities {
    get { return ActivityTarget.Activities; }
}

Adding extra properties to the IActivityTarget interface won’t be a problem:

public interface IActivityTarget {
    IList<IActivity> Activities { get; }
    bool Active { get; set; }
}

... because these properties will be contained in the ActivityTarget class, and the Contact and Account will redirect calls to it:

public bool Active {
    get { return ActivityTarget.Active; }
    set { ActivityTarget.Active = value; }
}

But this approach yields another problem – since we hide an indirection, any Activity-related criteria for, say, a Contact (“Activities.Count > 0”) will not be evaluated on the server, because there is no association between the Contact and Activity. As an alternative, we could translate “Activites.Count” to “ActivityTarget.Activities.Count”. This translation might not be very obvious and would lead to problems.

As you can see, that is something for XPO developers to think about. I’m going to talk to them and consider the approach we should use...

Good news! XPO can use persistent aliases to map the Account’s Activities to its ActivityTarget.Actvities. So, we will use the Intermediate Table approach with aliases, and we might not have problems related to criteria. My Activity components can work as is and I can proceed further while waiting for the XpoBuilder to generate what I want.

XCRM: Marketing Campaigns and Customer support

Roman Eremin — Tue, 07 Oct 2008 12:01:00 GMT

Marketing Campaigns

A Marketing Campaign has no relationships. However, a Lead and Opportunity may reference a Campaign:

[Test]
public void CampaignRelationships() {
    RegisterDC<ILead>();
    RegisterDC<ICampaign>();
    RegisterDC<IContact>();
    RegisterDC<IAccount>();
    RegisterDC<IOpportunity>();
    Generate();
    ICampaign campaign = ObjectSpace.CreateObject<ICampaign>();
    campaign.Name = "Playboy back cover";
    ILead lead = ObjectSpace.CreateObject<ILead>();
    IOpportunity opportunity = ObjectSpace.CreateObject<IOpportunity>();
    lead.Campaign = campaign;
    opportunity.Campaign = campaign;
}

[DomainComponent]
public interface ICampaign {
    string Name { get; set; }
}

[DomainComponent]
public interface ILead {
    …
    ICampaign Campaign { get; set; }
}

[DomainComponent]
public interface IOpportunity {
    …
    ICampaign Campaign { get; set; }
}

Instead of adding the Campaign reference property to both the ILead and IOpportunity components, I could add the ICampaignResult interface and inherit the ILead and IOpportunity from it. But I think, this is overkill. However, if one more class references the Campaign, and business logic is supplied for this reference, I'll choose this approach.

Cases (customer support incidents)

A Case is a record about a user's inquiry or problem. It is linked to an Account and/or a Contact. If the Contact is set, the Account is initialized from the Contact’s Account, if any:

[Test]
public void CaseRelationships() {
    RegisterDC<IContact>();
    RegisterDC<IAccount>();
    RegisterDC<ICase>();
    RegisterDC<IOpportunity>();
    Generate();
    IContact roman = ObjectSpace.CreateObject<IContact>();
    roman.FirstName = "Roman";
    roman.LastName = "Eremin";
    IAccount dx = ObjectSpace.CreateObject<IAccount>();
    dx.Name = "DevExpress";

    ICase case1 = ObjectSpace.CreateObject<ICase>();
    case1.Subject = "1";
    case1.Contact = roman;
    Assert.IsNull(case1.Account);

    ICase case2 = ObjectSpace.CreateObject<ICase>();
    case2.Subject = "2";
    case2.Account = dx;
    Assert.IsNull(case2.Contact);

    roman.Account = dx;
    ICase case3 = ObjectSpace.CreateObject<ICase>();
    case3.Subject = "3";
    case3.Contact = roman;
    Assert.AreEqual(dx, case3.Account);
}

[DomainComponent]
public interface ICase {
    string Subject { get; set; }
    IAccount Account { get; set; }
    IContact Contact { get; set; }
}

To make this test pass we need an extra code, in addition to the interface. We need domain logic for the ICase to initialize the ICase.Account property by the ICase.Contact's Account:

[DomainLogic(typeof(ICase))]
public class CaseLogic {
    public static void AfterChange_Contact(ICase self) {
        if (self.Contact != null && self.Account == null) {
            self.Account = self.Contact.Account;
        }
    }
}

Here is how we are planning to add domain logic to the classes that are generated by the XpoBuilder. We are going to use naming conventions. If the XpoBuilder finds a method named “AfterChange_XXX”, it tries to call this method in the generated setter of a XXX property. We'll probably add the attribute-based binding in the future.

A Case should have a human-readable ID that can be used in communications to quickly reference the Case. This ID should be generated only once, when a new object is beeing created. In addtion, the ID property should be read-only, but persistent.

Here is one more DC design challenge: how domain logic can specify the initial value of a read-only property? Should I add an AfterConstruction method to the business logic to set a value? But in this instance, I'll have to provide some system interfaces to call the ID’s setter. So, I think it is better to implement the Init_XXX domain logic methods that will allow you to set a property's initial value for a newly created object.

Since the ID property doesn't have a setter, it won't be persisted by default. To make this property persistent, I've decided to decorate it with the PersistentDc attribute. It could make sence to call this attribute Persistent, but in XAF this name conflicts with XPO’s Persistent attribute. So, it will be PersistentDc for now, and we will see what to do with it later.

[DomainComponent]
public interface ICase {
    [PersistentDc]
    string ID { get; }
    …
}

[DomainLogic(typeof(ICase))]
public class CaseLogic {
    public static string Init_ID(ICase self) {
        //ToDo: Change to "select count(*)+1 from case" analog
        return Guid.NewGuid().ToString();
    }
    …
}

This is a very simplistic implementation. I will return with a more realistic code, as soon we have a proper infrastructure.

SDN Conference next week

Oliver Sturm (Developer Express) — Fri, 03 Oct 2008 20:50:33 GMT

Just a quick note: I'll be speaking at the SDN Conference in Noordwijkerhout in the Netherlands next week. We're not exhibiting there, but of course I'll be looking out for DevExpress customers nevertheless - so if you're there, make sure to say hi! Of course I'll also appreciate you coming to my sessions on F# :-)

XCRM: Leads and opportunities

Roman Eremin — Fri, 03 Oct 2008 05:00:00 GMT

A Lead is not directly linked to a Contact or Account. It can be converted into an Account, Contact or Opportunity later. I’ll just capture the fact that the Lead class exists and may have some basic info:

[Test]
public void LeadsRelationships() {
    RegisterDC<ILead>();
    Generate();
    ILead romanFromDx = ObjectSpace.CreateObject<ILead>();
    romanFromDx.FirstName = "Roman";
    romanFromDx.LastName = "Eremin";
    romanFromDx.CompanyName = "DevExpress";
}

[DomainComponent]
public interface ILead {
    string FirstName { get; set; }
    string LastName { get; set; }
    string CompanyName { get; set; }
}

At this point, I’m not sure that the ILead should be inherited from the IPerson. So, I've just added the FirstName and LastName properties, and made a note to resolve this problem later.

An Opportunity is a more probable possibility for business. It is related to an Account (who you want to sell to) and Product (what you want to sell). Simple CRM systems do not track products and prices, so I will leave them out in our CRM app. Here is the test for Opportunities:

[Test]
public void OpportunityAccountRelationships() {
    RegisterDC<IContact>();
    RegisterDC<IAccount>();
    RegisterDC<IOpportunity>();
    Generate();
    IAccount dx = ObjectSpace.CreateObject<IAccount>();
    dx.Name = "DevExpress";
    IOpportunity sellComponents = ObjectSpace.CreateObject<IOpportunity>();
    sellComponents.Name = "Sell some third-party components to DX";
    sellComponents.Account = dx;
    Assert.IsTrue(Enumerator.Exists<IOpportunity>(dx.Opportunities, sellComponents));
}

To make this test pass I need the following:

[DomainComponent]
public interface IOpportunity {
    string Name { get; set; }
    IAccount Account { get; set; }
}

[DomainComponent]
public interface IAccount {
    …
    IList<IOpportunity> Opportunities { get; }
}

XCRM: Writing real-world CRM application

Roman Eremin — Wed, 01 Oct 2008 09:00:00 GMT

I'm starting to write a generic CRM application, to try the new domain component (DC) technology and decide what classes should be included in our Domain Component technology. This application should be suitable for small business and extendable to support specific markets. While writing, I'm sure to find bottlenecks in XAF that we will have to fix.

In general, a CRM application should be able to manage the following things:

Contacts
Accounts
Leads
Opportunities
Products
Appointments/Calendar/Tasks
Service Requests
Marketing Campaigns

In addition, even a basic CRM system should have a security system that is aware of organization structure.

To emphasize the most interesting design parts, I won't detail every domain class. I will create most classes in brief form, and then extend them as required. In the first iteration, I will focus on class relationships.

Contact. Can belong to an Account. So, it has the Account property.

Account. Can belong to another Account. So, it has the ParentAccount and Subaccounts properties. In addition, it should have a Contacts list, and a PrimaryContact, which may not belong to the Contacts list.

I’m using TDD, so I will capture this knowledge in unit tests.

Unit tests for Domain Components

To write tests for domain components, I think I will need a DC infrastructure to be able to generate components from interfaces and business logic. I won't use the entire XAF – I will need only small parts of its services. Here is an example of a test:

[DomainComponent]
public interface IBasicTestThing {
    string Name { get; set; }
}
[TestFixture]
public class BasicTests : BaseTest {
    [Test]
    public void TestBasicThing() {
        RegisterDC<IBasicTestThing>();
        Generate();
        IBasicTestThing thing1 = ObjectSpace.CreateObject<IBasicTestThing>();
        thing1.Name = "abc";
        ObjectSpace.CommitChanges();
        IBasicTestThing thing2 = ObjectSpace.FindObject<IBasicTestThing>(null);
        Assert.AreEqual("abc", thing2.Name);
    }
}

In all my tests, I'll register and generate domain components, and use an ObjectSpace object. So, all my tests will be inherited from the BaseTest class that will provide the required services. Look how it's implemented now:

public class BaseTest {
    private IObjectSpace objectSpace;
    private IObjectSpaceProvider osProvider;

    [SetUp]
    public virtual void SetUp() {
        XafTypesInfo.Reset();
        osProvider = new ObjectSpaceProvider(new MemoryDataStoreProvider());
        objectSpace = osProvider.CreateObjectSpace();
    }
    public void RegisterDC<T>() {
        if (typeof(T).IsInterface) {
            XafTypesInfo.Instance.AddEntityToGenerate(typeof(T).Name, typeof(T));
        } else {
            XafTypesInfo.Instance.RegisterEntity(typeof(T));
        }
    }
    public IObjectSpace ObjectSpace {
        get { return objectSpace; }
    }
    public void Generate() {
        XafTypesInfo.Instance.GenerateEntities();
    }
}

The SetUp method cleans up the current type information, and creates an Object Space using a newly created Object Space Provider (using in-memory data store). The RegisterDC and Generate methods work with the XafTypesInfo system, like it's performed in XAF.

Capturing domain knowledge in unit tests

I’m ready to write a test for the Contact - Account relationship:

[Test]
public void ContactAccountRelationships() {
    RegisterDC<IContact>();
    RegisterDC<IAccount>();
    Generate();
    IContact roman = ObjectSpace.CreateObject<IContact>();
    roman.FirstName = "Roman";
    roman.LastName = "Eremin";
    IAccount dx = ObjectSpace.CreateObject<IAccount>();
    dx.Name = "DevExpress";

    dx.PrimaryContact = roman;
    Assert.IsNull(roman.Account);

    dx.Contacts.Add(roman);
    Assert.AreEqual(dx, roman.Account);

    IAccount xafTeam = ObjectSpace.CreateObject<IAccount>();
    xafTeam.ParentAccount = dx;
    Assert.IsTrue(Enumerator.Exists<IAccount>(dx.Subaccounts, xafTeam));
}

Enumerator is a helper class from the DevExpress.ExpressApp.Utils.dll assembly. It provides utility methods for the IEnumerable interface (similar extension methods already exist in .net 3.0).

Here is the code that makes this test pass (remember – I’m focused on relationships, so don’t tell me that the IContact should contain the IPerson interface) :

[DomainComponent]
public interface IAccount {
    string Name { get; set; }

    IAccount ParentAccount { get; set; }
    IList<IAccount> Subaccounts { get; }

    IContact PrimaryContact { get; set; }
    IList<IContact> Contacts { get; }
}

[DomainComponent]
public interface IContact {
    IAccount Account { get; set; }
}

No logic is required, because the XpoBuilder automatically generates the correct associations and XPO manages them. So, when I add roman to the dx.Contacts list, the roman.Account property is initialized automatically.

DC: Implemented interfaces in BOModel

Roman Eremin — Wed, 01 Oct 2008 06:00:00 GMT

While playing with CRM domain models, I've got a component like this:

	[DomainComponent]
	public interface IContact : IPersonalContactInfo, IPerson {
		IAccount Account { get; set; } 
	}

This led me to one more issue that prevents XAF from working with the new models. I found out that the BOModel node doesn’t provide information about implemented interfaces. I would like XAF to treat implemented interfaces as it currently treats base classes – include base members into generated Views and reuse View Info provided for base classes.

So, to start, I need information about implemented interfaces in the BOModel. To make a long story short – here it is:

The next step is to make members of the implemented interfaces visible in Views.

DC: Thinking of base library

Roman Eremin — Tue, 30 Sep 2008 08:31:00 GMT

The new Domain Components framework will let developers create reusable domain components. Obviously, we should supply our variant of the domain component library. Our library should be full enough to let XAF developers start fast, and to provide a common well-established base for domain component developers. At the same time, it should be flexible enough to let developers replace or extend the parts that they don’t like.

I think, in the end, we will have our domain component library derived in two parts – very specific base components, which will be reused across all other components, and common domain components, which can be replaced or extended as required. Let me illustrate this approach.

Nearly every application needs information about a person. It can be just user information, or more detailed information on a customer, or very detailed information on a legal person. Obviously, there should be a base component Person, which will be referenced and reused by third-party domain components, and a real Person component, which contains more detailed information.

Components that reference the base Person don't need much information on it. So, it may contain a FullName and ShortName, and, in rare cases, Birthday and Gender:

    public interface IPersonRef {
        string FullName { get; }
        string ShortName { get; }
        DateTime? Birthday { get; }
	Gender Gender { get; set; }
    }

A real Person component may have more properties: FirstName, MiddleName and LastName, or GivenName, Surname and FatherName (depends on the culture). We should provide the Person that is sufficient in common cases – like this:

	[DomainComponent]
	public interface IPerson : IPersonRef {
		string FirstName { get; set; }
		string MiddleName { get; set; }
		string LastName { get; set; }
	}

You can use your own IPersonRef descendant in your application, instead of the IPerson. In this instance, all domain components that depend on the IPersonRef interface will work. For this purpose, we will provide a way to tell the system that "in this application the IPersonRef should be resolved into the RomanEremin.DC.General.IRussianPerson component".

Now, we are at the genesis of creating a base domain component library, and considering an approach to implement a useful one. I think we should start writing a real-world application (this has been requested for some time). While writing, we will get core, common and application-specific components that can be included in our component library.

What application should we write? I'm thinking of a generic CRM application. Most of us are intuitively familiar with applications of this type, so we won’t need to explain much, and most of us will be able to use it.

DC: Interfaces and BOModel

Roman Eremin — Tue, 30 Sep 2008 08:29:00 GMT

Now, while I’m waiting for the XPO team, who promised me to support new requirements, I've found one more problem. In my BOModel node, I can see the IDeveloper and INote interfaces, but I can't see the IPerson interface. Since our ultimate goal is to provide the ability to create reusable domain components, I want to be able to set up all XAF-related aspects of the IPerson in the Application Model, and then reuse these settings in all places where the IPerson is implemented.

But should I add all interfaces to the Application Model? What if the IDeveloper is inherited from the IDisposable, in addition to other interfaces? Should XAF add the IDisposable to the BOModel node? I guess not. There should be a way to mark the interfaces that are used for building entities later. I decided to add the DomainComponentAttribute that will serve as a mark:

	[DomainComponent]
	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; }
	}

Now, after I've refacored the code that analyses types inside XAF, the interfaces that use the DomainComponent attribute are added to the BOModel node:

Associations in DC

Roman Eremin — Mon, 29 Sep 2008 08:22:00 GMT

This post is one in a series about our work on Domain Components (DC) framework and related component libraries. I’m just describing what we are working on, what problems we are facing and what results we've got so far.

In my previous post I was looking at INote interface:

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

There is another thing I don’t like in this code: I don’t want the INote interface to know about the IItemWithNotes interface. But currently in XPO I have to define back references. Why? Let me explain the problem. Look at the class structure below:

    public class Developer : XPObject {
        private string name;
        public Developer(Session session) : base(session) { }
        public string Name {
            get { return name; }
            set { SetPropertyValue("Name", ref name, value); }
        }
        [Association]
        public XPCollection Notes { get { return GetCollection("Notes"); } }
    }
    public class Note : XPObject {
        private string text;
        public Note(Session session) : base(session) { }
        public string Text {
            get { return text; }
            set { SetPropertyValue("Text", ref text, value); }
        }
    }

These classes won't work correctly in XPO. In a relational database, a One-to-Many relation is performed by adding a foreign key to the table. For the classes above, you would create a table structure where the Note table has the foreign key column that stores a Developer's OID:

To retrieve the Notes that are associated with a particular Developer ID, you would write an SQL query like this: "select * from Note where Developer = <developer id>". XPO generates all queries for you. To generate the query I showed to you, XPO requires that the Note class has a property mapped to a foreign key column. In other words, the Note class should look like this:

    public class Note : XPObject {
        private string text;
        private Developer developer;

        public Note(Session session) : base(session) { }
        public string Text {
            get { return text; }
            set { SetPropertyValue("Text", ref text, value); }
        }
        [Association]
        public Developer Developer {
            get { return developer; }
            set { SetPropertyValue("Developer", ref developer, value); }
        }
    }

In this instance, XPO will find both ends of the Developer-Note association and create all necessary constraints and foreign keys.

But I’m working on the Domain Component library. My goal is to provide a framework for domain components – a puzzle's independent pieces. While writing the Note component, I don’t want it to know how anybody uses it. For instance, it can be used in the following entity (I know this is not a good design, but I still think it should be possible to do so):

    public interface IFullOfNotes {
        IList<INote> PublicNotes { get; }
        IList<INote> PrivateNotes { get; }
        IList<INote> DraftNotes { get; }
    }

To map the IFullOfNotes to the database, the Note table should have three foreign keys. If the XpoBuilder can generate back-reference (foreign key) properties automatically, our DC components will be much more flexible.

So, I want to write the following code in my Notes library:

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

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

I've added tests that express my desire. And again… I'm waiting for an answer from the XPO team. Stay tuned.

DC: One-to-many relationship

Roman Eremin — Fri, 26 Sep 2008 07:38:00 GMT

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.

Writing Domain Components framework (DC)

Roman Eremin — Thu, 25 Sep 2008 06:55:00 GMT

I'm starting a series of posts on my blog to share our experience while designing the domain component (DC) technology. It will be useful for us to know whether you like what we are doing. If not, we'll be able to correct our strategies early, before we make any mistakes.

I spent last month with the XAF Core team designing the subsystem that manages type information in XAF. Until now, the framework obtained this information directly from XPO metadata, sometimes using Reflection.

The new DC technology operates with interfaces. So now, the framework needs type information about interfaces. To get this information, we can't use XPO metadata, because it does not contain it. Even if we could, we don't like this approach, because we've targeted it to abstract away from a particular ORM tool. So, we decided to write a subsystem that would allow its users to avoid dealing with the sources of the type information.

When considering which approach to choose in implementing this system, Aleksey and Mike, developers from the XAF Core team, suggested an agile approach: we should refactor until the new subsystem emerges. I voted for the "Big Refactoring" approach: just write a new system, and then call it in the old methods and helpers. My approach would be faster, but it was going to lead to the crash of the entire system in a couple of weeks. This led me to do research, and partially write the type info subsystem in my private branch of XAF sources.

The next step was to integrate the new subsystem. Luckily, it was just after we had released the XAF 2008 vol. 2, the period when most of the XAF developers were busy fixing bugs and answering questions, and Aleksey was on vacation. This allowed me to convince Mike. We decided to integrate the new system and see how it behaved. Aleksey expected something like this from me. He even called us to ask if he should take one more week, so he wouldn’t see what we were doing. The next two weeks we were getting XAF back to the working state. Since then, we've been dealing with binding, type descriptors, complex property paths, structures, XPO dictionary (it directly affects what tables are created in the database), unit tests (should we reload type info between tests or not, you know, there are 1400+ tests), performance optimization and that sort of thing.

Anyway, it now seems that we have the type information subsystem working. This means that we can start creating a reference application using the DC base library. We will write this library as we go.

The base of the DC approach is the runtime interface implementation. In short, we write an interface for a domain object and a "domain logic" class that contains "non-obvious" parts of the domain object's implementation. This approach provides us with the following advantages: we avoid writing obvious code, remove dependencies on a particular ORM system, inject the aspects like security or remoting flexibly, and use multiple inheritance to construct the final application from blocks.

Real objects are generated from interfaces by the XpoBuilder class, written by the XPO team. This class is located in the XAF type information system. When you register an interface as an entity, the XpoBuilder implements an object for you. There is an important note here: you can build domain objects only once. After an object is generated, it cannot be modified.

At this point, I have the XpoBuilder working at some level, and need to have a few things implemented in the type information system. So, let's try to build an application using the DC approach.

Disclaimer: The code you see here cannot be run using XAF 2008 vol.2, or earlier. Moreover, I cannot be sure it will work in the final version of DC. This is just the code that works at the moment I wrote this post.

Let’s add a Person entity to our application. In the new DC approach, the simplistic Person library element may look like this:

	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;
		}
	}

Now, I need to ask XAF to generate an entity for it. For this purpose, I override the Setup method in my Module class in the following manner:

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

I call the GenerateEntities method here, because at this time XAF does not performs this call inside (I've made a note to correct this).

I run the Model Editor. As you can see, the IPerson entity is added to the BOModel node:

Expanding the Views node I can see that the List and Detail Views are already generated. Oops, I cannot see a child node representing the IPerson in the NavigationItems node. I've made a note to fix this. For now, I'll add this child node manually, together with the corresponding node in the CreatableItems node:

I run the application. In spite of the child node that I've added to the NavigationItems node, there is no "Person" in the navbar:

After some investigation it turned out that I have no permissions for the newly generated entity. The fact is that the SecuritySimple strategy assumes that we are working with objects only. Look how it gives permissions:

	public class SecuritySimple : SecurityBase  {
		...
		protected override PermissionSet ReloadPermissions() {
			...
				result.AddPermission(new ObjectAccessPermission(typeof(object), ObjectAccess.AllAccess));
			...
		}
		...
	}

Since an interface is not a descendant of the System.Object, I have no rights to it. I've written a unit test for XAF developers. It shows that their assumption is wrong. In order to proceed, I'll write my own SecuritySystem strategy:

	public class MySecurity : SecuritySimple {
		protected override System.Security.PermissionSet ReloadPermissions() {
			System.Security.PermissionSet result = base.ReloadPermissions();
			foreach(ITypeInfo entity in XafTypesInfo.Instance.RegisteredEntities) {
				result.AddPermission(new ObjectAccessPermission(entity.Type, ObjectAccess.AllAccess));
			}
			return result;
		}
	}

My Security gives all permissions to all registered entities (all persistent types). This is not a system you would like to have in a real application, but it will let me move on.

Now, I run my application, and "voila":

In the next post, I'll tell you about my efforts to associate objects using the One-to-Many relationship. Now, you are free to share your ideas on this post.

Constraints included - considerations on framework structure, architecture and evolution

Oliver Sturm (Developer Express) — Thu, 03 Jul 2008 15:22:00 GMT

Somewhere on a forum, I found people engaged in a discussion about various business application frameworks, and somebody commented (paraphrased): "XAF is probably not the right choice for us, as it seems constrain us too much with regard to applications we can build. The technical documentation describes a particular path that has to be followed in order to create an XAF application."

(Btw, this comment is paraphrased and not attributed to anybody because I don't have a way of finding out whether the original poster is fine with having his comment published and discussed here, together with his/her name.)

Well, this comment baffles me. Let's have a quick look at various hypothetical frameworks to see why:

Alma Knack, a C#/Windows Forms programmer who needs to prototype many new applications, feels that some of her work is redundant. So she creates a little library that makes it easier for her to create new applications from scratch. Most of her applications have splash screens, so she has a helper class for that. She takes the prototypes to other people and customizes them right there, so she also writes a feature that lets her change form layouts at runtime and import the modified layouts into her development code later. Since her applications are otherwise very diverse in nature, there's really not much more she can do. When she's tasked with creating a prototype of a little Tetris clone for Windows Mobile, to be given to customers as a gift, she can't reuse any of the code in her library.
Tad Pohl is a programmer in an insurance company. They have many different departments that work with custom applications. Of course there's always a large part of the functionality in any one of these applications that accesses common data, so Tad uses a common data access layer and many standard data layouts which he created for his two target platforms Windows Forms and ASP.NET. Since he's an OO fan, he structures his library well, which makes it quite easy for him to create the additional data views required by each of the departments. Of course his framework is specific to his domain of insurance data - creating an application for the HR department requires him to write almost everything from scratch, but then he doesn't normally have to do that.
Hugh Mungus is the lead developer in a company that specializes in SOHO productivity applications. Other teams in the company work on various applications for Windows Forms, ASP.NET and lately WPF and Silverlight. Many of these applications interoperate with Microsoft Office, Excel Services, SharePoint and SQL Server. Hugh's team works on a framework of data display and manipulation functionality for typical small business needs, and the framework can also create data bound Word and Excel documents and publish to the various server solutions. The new requirements of WPF and especially Silverlight represent a great challenge to Hugh, and a special requirement of a data mining feature that needs to access an Oracle database is almost impossible to implement for him.

So what can we learn from these scenarios?

Every framework is created for a particular purpose.
The functionality that's included is that which is common in the majority of applications the framework needs to cover.
The functionality that is *not* included is that which needs to be implemented specifically for most or all of the applications.
A framework is designed to make a particular task easier by providing ready-made solutions for the typical parts of that task.
There are always problems out there that a particular framework can't solve easily.

Okay. Now, does XAF constrain the types of applications you can build with it? Yes, of course it does. Or no, of course it doesn't. Hm... which one is it? Well, to give an example: the typical XAF application works with data in a database. If that's the type of application you want to create, then XAF is going to help you a great deal. But does it mean that you can't create applications that don't use databases? No, it doesn't. Only if you do that, then XAF won't help you as much.

Look at Windows Forms. If you want to create applications that have a typical main window, then Windows Forms makes that quite easy - you just derive your own form from System.Windows.Forms.Form, pass it to Application.Run and you're done. If you want customize something small, then you'll be able to hook into events or write method overrides in the form class to do it. If your form is supposed to be triangular in shape, have color effects in the background, a hole in the middle and shouldn't react to the mouse, then you might still be able to do it, but it gets more complex. If you want to run a secondary UI thread for your splash and status windows, that's when the standard mechanisms begin to fail and you have to do quite a lot of work yourself. If your application is Doom and you're using Windows Forms because of the nice MessageBox class, you've probably made the wrong decision entirely.

Back to XAF. The docs describe a particular way of creating an application that saves you as much work as XAF is able to save you. It is the most efficient way of creating an application if your basis is XAF, and if you want to use all the functionality the framework provides. If there's some part of the functionality that you don't want to use, that's typically easy - just deactivate it, or never call it. If you want to customize the built-in functionality, there's quite a lot you can do by way of options, custom pattern implementations and so on. If you want to replace certain parts of functionality with your own implementations, there are extensibility points that enable you to do this, and since our own modules aren't different from the ones you can create, we are pretty confident that custom implementations will work just as well.

What does that baffling commenter want us to do? Broaden the scope of applications that can be created easily? No, I don't think so - the phrase "it constrains us" doesn't seem right then, it should be "doesn't currently include that functionality". Of course broadening the scope of applications XAF can target is always something we work on anyway.

Second guess, does he want us to describe different paths of creating XAF applications, ones that don't take advantage of XAF functionality? Weird idea... why would we do that? Sounds like then we're back to basic ASP.NET or Windows Forms programming, and it's not our task to document that. Oh, we do write documentation about circumventing standard XAF features all the time - there's content on creating custom editors based on third party controls, for example, and I've recorded a video on extensibility of the ASP.NET application just recently. Of course there are a million things somebody might want to do in place of the standard features, so we're not likely to finish documenting them all anytime soon.

Third guess, he wants to create his application in precisely the same way as he's always done it, only he wants it to be easier. Yeah. Well. Perhaps a framework isn't really the answer then.

Generally speaking, there are certainly things that we need you to buy into in order to use XAF. Everybody who's ever created a framework knows that there are lots of small decisions to make on the way. We've made all those decisions, keeping things as flexible as we could along the way (which is probably something that Alma, Tad and Hugh above wouldn't do, since their situations are different), but still, we've made them. If some of these small things are really big for you and you don't agree with our solution... well, there may be only so much we can about it now, but please do let us know, it will make XAF better in the long run.

Bottom line: if your project doesn't need the functionality in XAF, don't use it. If the solution doesn't fit the problem, don't use it. It sounds simple, but it seems to be a word of wisdom these days. *cough*Ribbon*cough*Silverlight*cough*Astoria*cough*

Busy times

Oliver Sturm (Developer Express) — Thu, 19 Jun 2008 17:52:18 GMT

After coming back home from Orlando, I had two events to attend. The first was the brilliant UK NxtGenUG Fest 08 in Reading. This was a day of .NET topics and I presented on F#. I met a few of our customers there who hadn't made it to TechEd the week before, and I was glad to pass on all the news about awards, Silverlight controls and so on.

The second event I went to was a training event in Germany, where I did a day of C# 3.0 (and a bit of Developer Express as well... <g>). Again, I had a good time - if I met you at either of these events, thank you, it was good to talk to you!

Next week Gary and I are going to be in Glendale at the Developer Express office. As we already announced in the little interview we did at TechEd, we're going to start creating content on technical topics around XAF, and we're going to use the time there to create some video introductions. You'll probably see some of these appear on our site during the week, some others a bit later, so watch out for them!

No rest for the wicked - video announcements for XAF and XPO

Oliver Sturm (Developer Express) — Wed, 04 Jun 2008 02:06:00 GMT

... or the non-wicked, depending on your definition of "wicked" :-)

In between exhibition hours here at TechEd, Gary and I managed to get Jeff to record an introduction video with the two of us. We talk a bit about the other videos we're going to create in the next few weeks. Click here to watch it.

We don't have too many details yet, but of course it's about XAF and XPO and all the great things you can do with them. There's always been the problem that while both these products take away a lot of the work you need to do to create a data layer yourself (or even a lot more than just a data layer if we're talking about XAF), they still require certain knowledge and skills from the user. Nothing's for free in this world... (with the exception of our new Silverlight grid control, that is!) So we are going to create a bunch of content to target that problem particularly, to explain our product philosophy and generally help get everybody up to speed on things like designing domain class hierarchies, why ORM rulez and how you can do really crazy things in XAF, like create yet another blogging system. Some of this content is going to be in video format, some in written form -- it's probably going to be two or three weeks, but keep watching this space for it!

TechEd got off to a good start

Oliver Sturm (Developer Express) — Tue, 03 Jun 2008 19:37:23 GMT

The first half day at TechEd 2008 is over and we've already had really good crowds at the booth. Mark was doing CodeRush and Refactor! demos and he showed a lot of the new and upcoming features, which are really great. We also demonstrated our new WPF and Silverlight controls and I did some XAF presentations. Lots of people are interested in XAF and object/relational mapping in general, which is interesting to see -- apparently Microsoft's efforts with LINQ to SQL start paying off.

As I've blogged before, XAF is nominated as a finalist in the Best of TechEd awards, and one of the judges came around to interview me about the product this morning. I think he got a great impression of the product, so that's good, but of course the category that XAF is nominated for is very broad, so there are going to be other products that don't compete with XAF, but are good in their own right. We'll see how that turns out, but being listed as a finalist for the first TechEd after XAF was released is a nice success already.

So, more exhibition tonight at the attendees party, with food and drinks. If you're at TechEd, be sure to stop by and say hi!

Oh, did I mention how hot it is here? I'm melting away writing this -- the only thing hotter than I am is my computer. Time to stop :-)