Reusable Domain Models strikes back

XAF Team Blog
04 March 2008

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

In my first post about reusable domain models, I was looking for an elegant, intuitive and code-centric way in which to create domain models from existing parts. Since then we've done additional research. And now, I’m ready to share our results. I will describe the approach we're going to implement. Please note that some details might be changed. So, you cannot rely on this article as on a specification.

The main conclusion drawn from our research is that there is no elegant way to construct a domain model from existing parts. By an elegant and code-centric way, I mean the ability to look at domain class code and understand what’s going on. The approach we have chosen is that you provide logic and interfaces, and the framework builds an implementation for you.

Let’s consider one small and well-know domain model – Address. Address usually contains Country, City, State/Province, postcode, street address (or line1, line2). There can be one or several addresses. My requirements include:

  1. I want to be able to apply this model to any domain objects I want (Customer, Company, Contact, Location, Airport, Gas Station – anything).
  2. I want the business logic related to this model to be maintained by its developer. For bug fixes, he would give me only an updated assembly.
  3. I don’t want this model to depend on any ORM specifics.
  4. I don’t want to write lots of code to use this model.

With interfaces, I can make my domain model independent from my implementation. Here are simplistic Address interface definitions (please note that this code is just an illustration):

    public interface IAddress {
        IAddressable Owner { get; set; }
        string City { get; set; }
        string Line1 { get; set; }
        bool IsPrimary { get; set; }
    }

    public interface IAddressable {
        IAddress PrimaryAddress { get; }
        IList Addresses { get; } 
    }

Together with these interfaces, I should supply business logic. Since interfaces cannot contain method definitions, the only thing I can use is some kind of extension methods in the service class:

    [Service(typeof(IAddresable))]
    public static class AddressableService:EntityService {
        public IAddress Get_PrimaryAddress(IAddressable self) {
            if (self.Addresses.Count > 0) {
                return self.Addresses.Where(address => address.IsPrimary );
            } else {
                IAddress addr = SomeObjectFactory.CreateObject();
                addr.Owner = self;
                addr.IsPrimary = true;
                self.Addresses.Add(addr);
                return addr;
            }
        }
    }
    [Service(typeof(IAddress))]
    public class AddressService:EntityService {
        private IAddress self;
        private bool isPrimary;
        private bool lockPrimary = false;

        public AddressService(IAddress self) {
            this.self = self;
        }

        public bool IsPrimary {
            get { return isPrimary; }
            set {
                if (lockPrimary) return;

                try {
                    lockPrimary = true;
                    if (IsPrimary) {
                        foreach (Address addr in self.Owner.Addresses) {
                            if (Address != this) {
                                addr.IsPrimary = false;
                            }
                        }
                    }
                } finally {
                    lockPrimary = false;
                }
            }
        }
    }

As a domain model developer, I don’t need to specify anything else. This code assumes that the implementation of interfaces can persist its properties, service methods are called in the corresponding implementation, and that there is SomeObjectFactory that can create an implementation with a given interface. This service class will be wired into a generated interface implementation using naming conventions and/or attributes.

Even as a developer of a final application (that uses this Address model), I still don’t want to know how to implement a persistent property in the particular ORM I’m using. Or, if I do want to – I want to write it in one place, not in every single property getter and setter. I want to provide something like this:

    public class XPOPersistPropertyImpl:PropertyImplBase {
        private OfType value;

        public PersistPropertyImpl(string name):base(name) {
            this.name = name;
        }
        public  OfType GetValue(XPObject owner) {
            return owner.GetPropertyValue(Name);
        }
        public void SetValue(XPObject owner, OfType newValue) {
            owner.SetPropertyValue(Name, newValue);
        }
    }

So, I can imagine the entire application as a superposition of several domain models (one of them is an addition for the final application itself). Assume that we have a library of domain models (IOrganization, IAddress-IAddressable, IContact, ICustomer-ISale-ISaleItem-IProduct-IAgent, IEmployee-IEmployer):

    public interface ICar : ISaleItem {
        public ICarModel Model { get; set; } //Implements ISaleItem.Product
        public string Color { get; set; }
        public DateTime MadeOn { get; set; }
    }

    public interface ICarModel : IProduct {
        string Name;
    }

    public class MyObjectSpace {
        public static MyObjectSpace() {
            RegisterEntity("Company", IOrganization, ICustomer, IAddressable);
            RegisterEntity("Contact", IContact, ICustomer, IAddressable);
            RegisterEntity("Dealership", IOrganization, IEmployer, IAddressable);
            RegisterEntity("SalesManager", IEmployee, IAgent);
            RegisterEntity("CarModel", ICarModel);
            RegisterEntity("Car", ICar);
            RegisterEntity("Sale", ISale);
            RegisterEntity("Address", IAddress);
        }
    }

Who is going to implement all these interfaces? These implementations will be generated at runtime (we will probably provide other options in the future) using domain service classes, and any additional orthogonal services (like the persistent XPO property’s setter class, mentioned earlier).

An additional benefit of the described approach is that we automatically use a “programming against interfaces” approach, which can give us benefits of aspect-oriented extensions. We can add field-level security, and audit features. The interface can be implemented by some proxy class. So, we can even create an application server with remote objects from the same code. A multi-tiered application is something many of our customers have asked for.

If you only have interfaces, it is very easy to write unit tests for service classes. There are mock frameworks that will automatically generate interface implementations.

There is a well-known metaphor of the Dependency Injection (DI) container that can be used here to handle the model creation, and later the resolution of dependencies. We are going to build our own DI container that is tailored to our specific needs, and at the same time, is pretty generic to be used in other parts of XAF, or in your own use cases (OK, frankly – just to make Rinat Abdullin stop complaining that we don’t use IoC in XAF Smile).

A big problem here is indirection. Since you don’t have direct control over the implementation of your interfaces, it might be hard to diagnose problems. We should make some extra efforts to minimize side effects and make it easier to understand what’s going on.

This is what we will work on after 2008 vol.1 release. I doubt that this technology will be implemented in 2008 vol.2. Our target is 2008 vol. 3. We are likely to release some preview bits in interim.

52 comment(s)
Jascha
Jascha

Hi Roman,

It's been a long time coming! And perhaps still will be ;-) I completely understand that this is not trivial and there seems to be no obvious approach that ticks all the boxes.

After an initial read, what you have provided here looks very interesting and I like the introduction of the DI/IOC/Factory patterns, abstraction of the ORM and the support for distributed applications. There is a lot of auto-magic going on so I am very much still getting my head around how this might look in a real-world scenario. A few intial points that occur to me:

You appear to be using LINQ to abstract interactions with the ORM - is that fully expressive or will we be losing functionality that we currently have with the likes of XPO?

How will we be able to use/define ORM-specific functionality such as delayed loading / pre-fetch, property converters etc.?

Will interface inheritance be equivalent to class inheritance if we are using XPO?

What strategies will be available for mapping these interfaces / entities to tables?

Will the interfaces be decoratable with all the XAF attributes?

How will the DI be configured - i.e. can we configure which implementers it will use? On a per-Entity basis?

It looks like a fair amount of additional processing and indirection is being introduced (e.g. building the domain model at startup and in the property accessors at runtime) - will this have a significant performance hit?

A minor issue, but I am not sure that the classes you are calling Service... are aptly named. It may just be my personal preference, but my assumption about a "service" class is that it belongs more in the business process layer as opposed to the domain layer.

Since the entities you are composing are not compile time classes, how would you access those from an external business process service class? E.g. in your example, how would you request a list of dealerships?

What tools will you provide the developer to build these domain models?

How much of this technology will be usable outside XAF?

Do you think that this may be another steep bit of learning curve to XAF newbies that might be a barrier to adoption?

I guess that's enough for now!

Regards,

Jascha

4 March, 2008
Christoph Brändle
Christoph Brändle

well, sounds good, but what for?

honestly, XAF maybe good, but does not save the world, neither it is good enough for wide spread use, but the ActiveX and WinForms Controls from devExpress are..

there was a time i said to myself: i wait for devExpress until they bring WPF Controls, now I say, what ever they do, hopefully some other vendors bring good WPF Controls, so devExpress gets a kick to do something...

4 March, 2008
Jascha
Jascha

Christoph,

Why do you think that XAF is not good enough for widespread use?

And how do you propose to save the world with DX controls? ;-)

Jascha

4 March, 2008
Roman Eremin (DevExpress)
Roman Eremin (DevExpress)

> You appear to be using LINQ to abstract interactions with the ORM - is that fully expressive or will we be losing functionality that we currently have with the likes of XPO?

LINQ is even wider than XPO's criteria language.

> How will we be able to use/define ORM-specific functionality such as delayed loading / pre-fetch, property converters etc.?

I'm thinking of using attributes. Probably in the end we will have several ways to alter object generation process.

> Will interface inheritance be equivalent to class inheritance if we are using XPO?

I think so. With benefits and drawbacks of possible multiple inheritance.

> What strategies will be available for mapping these interfaces / entities to tables?

I don't think that strategies will change - everything XPO supports right now will be supported with new approach.

> Will the interfaces be decoratable with all the XAF attributes?

Yes

> How will the DI be configured - i.e. can we configure which implementers it will use? On a per-Entity basis?

I'm thinking of combination of explicit configuration with some heuristics to make process less complex. Our DI container should be fexible enough to let you add/replace configuration strategies.

> It looks like a fair amount of additional processing and indirection is being introduced (e.g. building the domain model at startup and in the property accessors at runtime) - will this have a significant performance hit?

I don't expect serious performance hit at runtime. Regarding startup time it is true and probably we will have to provide some alternative generation options like post-compilation action. We will optimize what we will have.

> A minor issue, but I am not sure that the classes you are calling Service... are aptly named. It may just be my personal preference, but my assumption about a "service" class is that it belongs more in the business process layer as opposed to the domain layer.

Good point, we will think of better naming.

> Since the entities you are composing are not compile time classes, how would you access those from an external business process service class? E.g. in your example, how would you request a list of dealerships?

In your example I would create

IDealership: IOrganization, IEmployer, IAddressable

interface and registered it alone.

> What tools will you provide the developer to build these domain models?

Can't think of any at the moment, but we always open for suggestions.

> How much of this technology will be usable outside XAF?

I guess it will be fully usable outside XAF.

> Do you think that this may be another steep bit of learning curve to XAF newbies that might be a barrier to adoption?

This approach will let us create truly independent reusable domain models. So though it is less trasparent than current BCL, you will start your application with hundred domain modules, instead of building entire domain model from the groud up. So ultimately I guess it will be easy to build an application than it is now.

4 March, 2008
Anonymous
Fredrik Kalseth

This sounds very interresting :)

Have you looked at <a href="iridescence.no/.../Composite-Oriented-Programming.aspx">composite oriented programming</a>, which what you talk about here shares several ideas with? The Java framework <a href="http://qi4j.org">Qi4j</a> has been doing some very interresting pioneering in this area.

4 March, 2008
Jascha
Jascha

> LINQ is even wider than XPO's criteria language.

Ok but XPO provides facilities such as querying in transaction / database only with subtle semantic differences - presumably these things will become unavailable? It might be reassuring if it can be structured such that we can use ORM-specific functionality if we find we need to so that we knnow that there will be no dead end gotchas lurking in the detail fo the new framework.

>I'm thinking of using attributes. Probably in the end we will have several ways to alter object generation process.

Ok attributes and not naming conventions, please!

>I don't expect serious performance hit at runtime. Regarding startup time it is true and probably we will have to provide some alternative generation options like post-compilation action. We will optimize what we will have.

Definitely provide optimisation options. The main complaint I have from clients re. XAF applications is the slow start up time (less of a problem) and slow performance opening windows (a bigger problem). Any significant slowdown will be fairly painful and might start to turn people away from XAF.

>In your example I would create IDealership: IOrganization, IEmployer, IAddressable interface and registered it alone.

Sounds like that would be the normal pattern of usage so you have compile time entities to work with.

>Can't think of any at the moment, but we always open for suggestions.

Well the current module editor could be extended to allow "business classes" to be composed of the various interfaces containded in the module(s).

>This approach will let us create truly independent reusable domain models. So though it is less trasparent than current BCL, you will start your application with hundred domain modules, instead of building entire domain model from the groud up. So ultimately I guess it will be easy to build an application than it is now.

On the surface that sounds great. Can I get my vote in early that you try to avoid creating a US-centric set of domain components or, at least, ensure that you provide (or it is easy to plug in) entities that are applicable to other markets / cultures etc. In fact, could you generate culture-specific models depending on configuration? E.g.

IAddress (culture agnostic)

{

Street1,

Street2,

City

}

IAddressUS : IAddress

{

State

Zip

}

IAddressUK : IAddress

{

Building,

Postcode

}

etc. and the generator could plug in the correct descendent? Not sure if that is workable or makes sense but it may be an idea to consider!

Regards,

Jascha

4 March, 2008
Roman Eremin (DevExpress)
Roman Eremin (DevExpress)

Fredrik:

Thanks for the link it is very interesting!

Jascha:

Thank you for the great feedback. We sure will consider your suggestions.

4 March, 2008
Christoph Brändle
Christoph Brändle

>Why do you think that XAF is not good enough for widespread use?

>And how do you propose to save the world with DX controls? ;-)

Jascha,

dont get me wrong, a lot of people are doing a great job at devExpress. XAF is neat, but has a short lifecycle. the reason is easy to see, look at the time it needed from start until it got mature. is it really mature? try to create an email client for example with XAF, I wonder how far you got. I have seen many Codegenerators on DOS, and remember well Clarion, all gone (or nearby).

why do DX control save the world more likely: give a programmer good controls and he can spend his time on good architecture, and can be geeky, find ways, look on codeproject what people get out of the things, amazing.

but my point is a different one, devExpress is pushing XAF (because they invested so much time, they want it to succeed. this is one of the most common mistakes companies do, they can not let go at the right point). all the stuff they really had success on, they lost their superb start position, just count the TBD's that are older than one year. look once at simulsoft reports, so much better than xtrareports, only the xtrascheduler is unbeatable..

i just wished they pushed future more (WPF, Silverlight), and less XAF/XPO integration but more service oriented architecture. if this continues, devExpress will not succeed because XAF/XPO has to be integrated... what a pitty for all those that dont use this stuff (i guess 95%)

Cheers, Christoph

4 March, 2008
Rinat Abdullin
Rinat Abdullin

Christoph,

I absolutely agree with you.

XAF is a dead-end since it has the screws fastened up too tightly in order to feel like an easy start. Extensible modular framework (just a level above components to give bigger building blocks) with reference implementations and development guidelines would've been more popular. And it would be worth getting Universal for this one.

However, there is one nice side effect of XAF. Its development has forced existing DXperience tool set to become a bit more solid and open to integration.

Best regards,

Rinat Abdullin

4 March, 2008
Rinat Abdullin
Rinat Abdullin

Roman,

I'm not complaining (I would have to use XAF live in order to get the right to do that)))

I just wish you've used more IoC modularization and extensibility in the right spots of it (wild IoC usage just kills the mainability).

IThe idea behind XAF has great potential (i.e: reusability of DesignLayout-based designs on different platforms, XAF-hosted workflow automation, distributed data entry in flexible forms for web clients and rich desktop UI to work with that data, efficient on-the-fly configurability and extensibility that does not kick the TOC up etc), but the implementation slows it down quite a bit.

BTW, IoC at the ORM level just does not feel right. I've attempted to hook these together a couple of days ago (one of the commenters in my blog has been curious about the idea) and the resulting code just didn't look nice. At least XPO+scoped IoC didn't want to work out well at the construction stage of BOs, since the constructor is created within the reflection ClassInfo object and the latter is shared between multiple sessions and scopes.

And for the reusability scenario... well we found only one efficient (but partial) solution for that: inherit bindable objects from XPIdentity (Guid as Oid), make reusable objects (Task, Contact, Document, Comment etc), implement some IOwnedRecord interface that includes storing owner Oid and owner table name (this one, JIC). It is cheap, but works for simple scenarios and requires just a config change (could be done on-the-fly) to let Web&Desktop users comment on some BusinessProgramEntry.

best regards,

Rinat Abdullin

4 March, 2008
Michael Palmer_1
Michael Palmer_1

I don't know what you're complaining about with XAF/XPO. It seems to me that you are trying to be purists, who follow the latest ideas about architecture, which is fine in its own regard, but for the rest of us who have a job to complete do not have the luxury of coding philosophy and prefer, rather, to provide solutions for our paying customers.

So, while you're trying to build the eiffel tower with code, I'm out providing my customers solutions built on XAF/XPO and getting paid handsomely to do so.

So far, in 2008 alone, I've completed 7 implementations with XAF totalling a little over $32,000 in billing. And, I'm a one-man show. Not bad considering my overhead during that same period was less than $6,000. So, DX, XAF, & XPO has helped net $24,000 in two months.

Try pulling that off with any other development suite of tools. I've been a developer for 10 years and I've never been able to be so productive without having a team around me. Once I build a team in my new location, we'll continue to use DX tools and the money will keep rolling in because we can finally produce high quality apps in a short amount of time.

Keep up the good work DX, you guys are paying my bills and I'll continue to help you pay yours.

4 March, 2008
Mohsen Benkhellat
Mohsen Benkhellat

I like this idea of persisting interfaces instead of classes. I had a typical case with XAF in having to manage login (using ComplexSecurity) for both Customer (external) and Employee (internal) business classes and this feature would have helped me a lot.

On a side note, I hope auto-referencing (ITreeNode) wil still be supported.

Question 1: Do you mean by EntityService (LINQ) an independent way of storing each entity (one could be from web service another from database)?

Question 2: Can we hope the ability to alter dynamically interfaces (add or remove persistent properties) ?

Thanks anyway for making it happen

Mohsen

4 March, 2008
Christoph Brändle
Christoph Brändle

Michael,

no-one is complaining about XAF/XPO, but I am really glad you wrote your statement, it is the exact mirror of the problem about this hype (that will be gone soon I hope)

devExpress had success because they had the best Controls. with that money they made more Controls, more success, more money. But instead of really having the best Controls in future, they decided to have this XAF/XPO things. sorry, but I will buy other vendors (you name them) if they have better Controls. You seem to profit from that, good for you. I mean a lot of people made applications with MS-Access, nice too. but devExpress should keep in mind, they got succesful of people that needed their Controls because they wanted to do better, ans certainly want to do better than XAF.

I like devExpress and suffer because I can see that company is going down, slowly but they are. If they bring a really good Editor/Grid Suite on WPF this year, ok, I will be quiet, but as it seems, they wont (because of XAF?).

is there more people thinking like me or should I better shutup and change my favourite tools-supplier?

4 March, 2008
drew..
drew..

This is the third iteration of my attempt at posting here. I will be gentle: there is no pressure on anyone to stay here with DX. The inherent criticism found between the lines here towards xaf and those of us who are on-board with it is a tad distasteful. Let's get back to real business.

4 March, 2008
Christoph Brändle
Christoph Brändle

oh, now the things get personal, i did not intend, so this is my last post. maybe you are right, I better think about cancelling my DX-subscription, I even paid for XAF... even I could post in the first attempt.. :), Cheers

4 March, 2008
Evgeniy Meyke
Evgeniy Meyke

This argument reminds me "digital vs. traditional photography" discussion... for some reason...

I am with Michael on this one.

4 March, 2008
Linton
Linton

The idea is somehow that DevEx cannot focus on more than one product: That's simply not true. XAF uses a different team, don't fret, the WCF team are happily working away...

Installing a commercial XAF app next week, the port was flawless, the framework allows me to focus on business logic.

I use it.  

4 March, 2008
Rinat Abdullin
Rinat Abdullin

Drew,

we criticize because we worry and care.

I love DX and I wish XAF would've been better - then I could forget about xLim and stick with DX-supported solution. And I know that XAF could be much better

.

Unfortunately right now it seems like its development is heading dead end.

Evgeniy,

One does not have to go completely digital, but getting modern Zeiss optics and proper light equip. is something that could make positive impact on the traditional photo as well.

Michael,

Thank you for your post.

That's definitely something really inspiring for me.

Best regards,

Rinat Abdullin

4 March, 2008
Sebastia Prat i Pons
Sebastia Prat i Pons

I'm with Micheal and with Evgeniy and Linton too.

There are infinite ways of making applications, and XAF bring to us the ability to do in a clean way, quick and customizable. For me is the best RAD environment I've found. I prefer to focus on business logic also.

I've developed some small development frameworks in the past, with VB6, .NET 1.1, .NET 2.0, and now I prefer to focus on making applications than devolopment frameworks.

For sure, I'd like to have more features with XAF: integration of all controls that they have; more UI performance; persist the user model in the database to allow the user to share it between machines; a service layer in the server to focus the critical operations on the server to get reliability and performance and also with WCF over Internet; best end user reporting designer; a model designer tool to be able to design the model outside from the code, the relations, the custom attributes, the usual attributes. But the product has to grow and DX people are working to do so.

[Any of my customers had asked for WPF ...]

Congratulations for the good job!

OOps, I like the model that you explain, I'm not sure if I understood it fully, but I'll study it in detail.

Regards from Catalunya (Spain)

4 March, 2008
Evgeniy Meyke
Evgeniy Meyke

Rinat, imagine what Zeiss optics and proper light equipment could do for digital... ;)

I agree that "XAF makes it feel like an easy start" but the thing is that it also makes it feel like an easy finish (without sacrificing overall quality and stability) for the substantial amount of projects as i understand. Oh well, at least for Michael's :)

4 March, 2008
Rinat Abdullin
Rinat Abdullin

Evgeniy,

Thank's for that point. I think I see now why there's a bit of tension over XAF.

Basically everybody has their expectations for XAF. It meets some and fails the others. XAF is extremely good at fast and shiny delivery of information management applications that can fold along the flexibility points provided by DX team. Additionally it has some solid support behind, thus providing ability to deliver production-level solutions quickly.

So although XAF is like game with big building blocks, but it is enough to deal with 80% (normal probability distribution thing) of information management problems that take place in organizations. That brings business value.

And the developers worried about XAF have just happened to hit 20% of usage scenarios that require more diverse and complex business toolset in order to be solved.

So may be in the Universal subscription one day there will be one.

Rinat Abdullin

4 March, 2008
Luc DEBRUN
Luc DEBRUN

I have to disagree with Michael Palmer and yet explain why I am a strong supporter of XAF.

The Whole world (and I mean that) is watching us on how we are supposedely inefficient. Yet, member states give us litterally peanuts to develop our IT tools (the ones we need on a day to day as opposed to the large infrastructure which they are - in my personal opinion - overpaying).

Practice has been to recruit one man show type of businesses because we could not pay for the larger more established companies. That resulted in a myriad hacked up applications with little documentation and when we needed maintenance we would have to re-higher someone which would generally trash the previous app.

With XAF we developped our first XAF app, in house, with very little help from an outside consultant (less $1500), and in a matter of a few working days.

We are rating this app as equal or better to what we would have gotten with prior practice for a fraction of the price. The technical documentation (which is often neglected with one man shows) is there already (I can already here comments on that but we think it is ok). We only need to spend a little time explaining the classes and controllers we added. Also, say we develop (an)other XAF app, the maintenance costs are reduced. And then, for me, the cherry on the cake was when the end user kept asking me to move a field left or right or add this or delete that - After a little while the end user understood how the layout control worked and started playing with it herself.  

As of today, XAF fills appears need that my organization has. We are happy to try it out further this year with a couple more of applications. We cannot be more encouraging to Dx to continue developing this.

Other real developers can continue to theorize on the best way to develop what they think is a real world application. As far as I am concerned, I just started improving my back office with one.

And a last note. As far as I am concerned, XAF is helping save the world as of last week. Because, any help we get to improve our back office will free resources of my colleagues to help those governments which call on us.

Luc Debrun

UN-ESCAP

4 March, 2008
Tore Andre Brakstad
Tore Andre Brakstad

XAF might be great for some. However, I think DX should focus on what they do better than most, creating great components. XAF is a good example of how to create an application framework using DX components. But I think DX should use it as "look what you get " advertising for the component suites. As a standalone product (pretty expensive as such) I think it will die.

5 March, 2008
Mark Krasnohorsky
Mark Krasnohorsky

About 5 years ago, I met a guy who wrote everything in assembler, I thought he was nuts. He told me that is the only way you can get proper use of memory and the microprocessor. I guess I could not disagree with him. I am not sure why there exists this artificial distinction between "components" and "frameworks". I like to think of the progress of software development as a continuum not as a set of distinct categories. Thus, to me XAF is the introduction of what could be called as "next generation" components. It simply just does more for you.

What I am absolutely most amazed by with XAF is that I have completed several projects with it now, and I still have not hit a wall with respect to making it do what I want it to do while still working mostly within the confines of the XAF framework. To me this is one of the greatest accomplishments for XAF.

I think that it is extremely dificult to create a framework that both does lots for you and is still flexible enough to accomodate major functionality changes. I believe that this is precisely because of DX experience with creating components.

5 March, 2008
Linton
Linton

Very well said, Luc. XAF tames the maintenance monster we as application developers face day-to-day.

I make a distinction between application developers and architecture developers on purpose. There are clearly two types of software developers posting here...those types who are "architects" (very smart, indeed) and those who are "builders" (very clever, indeed).

They both thrive because of the other. Builders thrive (financially) because we have the excellent tools and frameworks the architects have produced, architects thrive (financially) because they have the builders who buy and use the tools and frameworks they create.

It is good to see the arcitects "push" DevEx to be more excellent, and it is good to see builders prove their designs in production.

Kudos to the architects, for the builders (like myself) could not thrive without you, continue to be patient (and persistent) but understand that DevEx can focus on more than one thing at a time...the XAF framework and the underlying components.

5 March, 2008
Ray Navasarkian (DevExpress)
Ray Navasarkian (DevExpress)

Holy Cow!

These days, my goal is to reduce the number of white hairs on my head, and not to add to the growing population...so I try to stay away from such threads...but I just could not help myself.

First, Second, and Third point I want to make...XAF is built by a team whose focus is XAF. This product does not adversely affect any other product. Fact is, that the XAF team does a great deal to improve the overall usability of our controls ... they use these controls everyday and therefore see their strenghts and weaknesses just like you do.

As far as frameworks are concerned...we knew full well that discussions such as these would develop over time. Heck, once we initiated this project, the same discussions that appear here, happened at DevExpress. From excitement in some to lukewarm acceptance in others to outright questioning of the logic in entering this product space.

All of that to me is a very good thing. I've learned over the years that no one has the "one" answer to anything. Opinions are valuable and must be weighed against a whole host of variables.

XAF will evolve and mature and our commitment to it is firm. Many people are delivering solutions built upon it and can't say enough good things about XAF. We saw a stampede to renew Enterprise licenses to take advantage of the free 1 year license offer in December and many cited XAF as the reason they wanted to renew in Dec. This of course wont make you happy Christoph, but my post is not intended to do so. I realize I wont satisfy your desires with anything I say. You are convinced of the merits of WPF as are many others. We have actually had to use it and know of its limitations. The future will be quite rosey for WPF, but XAF is not why we decided to wait for others to burn their hands first.

5 March, 2008
Linton
Linton

Ray,

"These days, my goal is to reduce the number of white hairs on my head..."

It is a futile pursuit, besides (as someone once said) "A grey head is a sign of wisdom" ;-)

5 March, 2008
Christoph Brändle
Christoph Brändle

Ray, dont worry, even I hoped there is good news about WPF, I certainly knew there is not right now, the why is still a miracle though.

if it helps I can send gloves to the WPF team :)

5 March, 2008
Jascha
Jascha

Hi Rinat,

I am interested in your posts here because from those of yours that I have followed on the newsgroups, your opinion seems very worthwhile. I would love some insight into how you can jump from this statement

"XAF is a dead-end since it has the screws fastened up too tightly in order to feel like an easy start."

to this one

"So although XAF is like game with big building blocks, but it is enough to deal with 80% (normal probability distribution thing) of information management problems that take place in organizations. That brings business value."

within a day!

The purist and enthusiast side of me would love to spend a year or two creating a framework. I spent some time looking into frameworks such as SCSF (look what happened to that) and then a few months creating my own framework before I came across XAF. My main criteria were that it should boost productivity for the typical line of business application, allow me to create quality apps. and not prevent me from dropping down to "normal" development if a particular feature requires it. On balance I think that XAF ticks those boxes. Additionally, I had to bow to my own market forces and produce revenue-generating products which XAF is eminently good for - my invoices have all been paid!  Sure it isn't perfect and there are many things I would love to change but the bottom line is that does allow us to create the 80% of line-of-business type applications that you refer to and therefore, from my perspective, it is a very pragmatic choice. Over the years I have witnessed (and participated in) many discussions about the current hot topics like client-server, distribution, SOA, correct pattern usage, AOP... IMO, while there is merit in taking onboard what you consider to be worthwhile from those discussions, unless you monetise them by becoming a high-profile flag-bearer for the next industry bandwagon, they produce more hot air that usable software / revenue.

IIRC we had a brief exchange on the newsgroup in which you were going to elaborate on your specific reasons for not seeing XAF as a viable tool for your purposes and I would still be interested in hearing your reasons because I cannot believe that it is solely down to a lack of flexibility and sufficient use of DI/IoC. Surely if that is the case then there would still be a worthwhile ROI in using XAF for the 80% of applications for which it is suitable and "traditional" tools for the rest? If you do answer, it may be best to do so on that thread since we all seem to be hijacking this post to vent our opinions about XAF which I suspect was not Roman's intention!

Regards,

Jascha

5 March, 2008
Jascha
Jascha

Roman,

One more thought. Please try not to exclude the use of normally coded domain models when you introduce your proposed reusability enhancements. I do share some of what I suspect are Rinat's concerns about it potentially sacrificing comprehensibility and manageability to achieve reusability. Knowing that your extensions are an option and not a requirement would be comforting.

Jascha

5 March, 2008
Alex Hoffman
Alex Hoffman

XAF is no doubt a good framework for some scenarios, not so good for others.  The problem in IT is that people want to find a "silver bullet" solution that can become the basis for all their development.

I agree with Rinat about the 80/20% rule.  It's the 20% that will be unproductive, as one tries to work out how to fit those non-standard requirements into a product that didn't envisage them.

I'm reminded of United Technologies purchase of Chubb PLC (security).  UT decided to write off US$100 million in PeopleSoft development, because Chubb in their wisdom had decided that PeopleSoft would be the development platform for all systems.  Worked great for 80% of their line of business systems, but just didn't cope with the remaining 20%.

Alex

6 March, 2008
Rinat Abdullin
Rinat Abdullin

Jascha,

1. That's simple.

One can deliver development solutions with XAF and they will work and be stable.

And at the same time:

1) XAF-based solution is a dead-end for any long term development. More time you spend on some project more often will you test your new functionality-to-be-added against the 80/20 probability.

2) development of XAF platform is a dead-end on its own. It will be too resource-expensive for the DX team to add new features/extensibility (leading to these numerous TBDs on XAF) or refactor the system.

2. You do not have to spend 2 years to build a framework. If you systematically collect the knowledge you can implement it and the current reference implementation from scratch within couple of months with a mid-sized dev. team.

Additionally there is simple economic reasoning behind this approach: my invoices end up in more tasks to be done or attempts to sign me up for FT job. And I'm not the enemy of myself to deliver solutions that it will be resource-expensive to evolve in the long term according to the customer's wishes.

Normally, when you need to implement something new, the framework should fight for you, instead of fighting you back.

3. I remember my promise to write about XAF limitations.

Rinat

6 March, 2008
Rinat Abdullin
Rinat Abdullin

Jascha, Roman,

my concerns about this RDM idea are simple:

1) "We are going to *build our own* DI container that is *tailored* to our *specific* needs".

2) looks like too much code for me.

Rinat

6 March, 2008
Roman Eremin (DevExpress)
Roman Eremin (DevExpress)

Great to see we are back on topic!

>my concerns about this RDM idea are simple:

> 1) "We are going to *build our own* DI container that is *tailored* to our *specific* needs".

Right. We cannot just use third-party containier, expecially an open-source one, because we do have obligations to fix bugs quickly. So we need our own, so we own the code. Even if we will base our container on some existing open-source one (if license permit - i like ninject) we will have our own branch where we own the code. I also mentioned that this container will be generic enough to be used for non-XPO/XAF purposes - this is important.

> 2) looks like too much code for me.

If this point about RDM - too much code comparing to what? Comparing to the current BCL approach new domain modules will contain much less code (because there will be no persistent properties implementation defined there).

6 March, 2008
Jascha
Jascha

Rinat,

>

1) XAF-based solution is a dead-end for any long term development. More time you spend on some project more often will you test your new functionality-to-be-added against the 80/20 probability.

<

You seem to be assuming that all applications will eventually encompass all types of problem domain and therefore hit the 20% at some point. I'm not sure that I agree with that - I cannot envisage the kind of line of business applications that I am targeting needing to be real time, graphically intensive or to require a prohibitive proportion of specialised UI's. Clearly, I have to be careful not to take on projects that carry a significant risk of that eventuality but that is a commercial constraint I accept.

>

2) development of XAF platform is a dead-end on its own. It will be too resource-expensive for the DX team to add new features/extensibility (leading to these numerous TBDs on XAF) or refactor the system.

2. You do not have to spend 2 years to build a framework. If you systematically collect the knowledge you can implement it and the current reference implementation from scratch within couple of months with a mid-sized dev. team.

<

With all due respect, 2) seems to be a bold claim given that I guess you are not initmately aware of the internal economics of DX. I agree that XAF is a new area for DX and carries a higher risk for them but from what I can see, they have succeeded so far where many have failed.

Once again I am a bit confused at the apparent contradiction between 2. and 2) - that XAF will be too resource-expensive to be viable but your team can create a framework in a few months. Either they are very different in scope in which case any comparison is unbalanced or DX should hire you immediately!

>

Additionally there is simple economic reasoning behind this approach: my invoices end up in more tasks to be done or attempts to sign me up for FT job. And I'm not the enemy of myself to deliver solutions that it will be resource-expensive to evolve in the long term according to the customer's wishes.

<

Sorry - I am not sure I follow you here - what exactly is your business model? Surely the original purpose of this thread was to inform about a strategy for reuse that allows us to realise the economic benefit of the multiplier-effect - i.e. being able to resell reusable system components.

>Normally, when you need to implement something new, the framework should fight for you, instead of fighting you back.

Well if you can create a framework that addresses all future requirements without friction then I salute your achievement and you may just have discovered the elusive silver bullet. I guess the rest of us will have to start looking for the gold one now ;-)

>3. I remember my promise to write about XAF limitations.

I look forward to it and I suggest we cover what mileage remains in this discussion there.

Jascha

Roman - I apologise - this will be my last off-topic post.

6 March, 2008
Mark Krasnohorsky
Mark Krasnohorsky

Hi Roman,

I would also like to see this approach taken for the XAF application model. (Typos in the strings required to access the application model data are beginning to drive me insane.) I also think that extending the application model through the use of interfaces as opposed to procedure hooks allows for better encapsulation of code. As the extension to the model can clearly be seen at the class level as opposed in some XML file or procedure in the module initializer.

6 March, 2008
Rinat Abdullin
Rinat Abdullin

I'll try to be short))

Roman,

1) spiking DX-owned (and supported) branch of any open-source container would be the best option in terms of investment/gain ratio. The containers that are out there - have already won the world competition and have been polished by numerous implementations. Plus the DevExpress could get numerous synergy benefits from that (marketing will know))

And if you decide to spend some resources on IoC development, then, please, do not forget about proper scope support and deterministic component disposal.

You might also want to check my latest post on extremely simple IoC+XPO integration at http://rabdullin.com Maybe there will be some ideas.

Jascha,

1. XAF is a dead-and since it has too much excessive and limiting code. Refactoring will not help and it is psychologically hard to drop the code and start from scratch.

2. Yes, it is possible to re-create flexible business framework in 2 months (including Web+Server+Engine+Desktop). We've done that. But we've cheated - we've used all the previous experience, numerous efficiency ideas from the web and bugged the customer about all his business plans and dreams for the next year (just to be prepared).

3. There are no silver bullets as we all know. But if you do not stick to hard code and spend an immense amount of time and dead brain cells on planing and considering primary future requirements along with the probabilities, risks and constraints, then you might get result that acts as silver bullet for the specific project goal to be hit.

Best regards,

Rinat

6 March, 2008
Andreas Mummenhoff
Andreas Mummenhoff

Hi Roman,

one question: What do you mean with "Since interfaces cannot contain method definitions"?

From practical view, I can define methods in interfaces - do you want to say that interfaces, which contain methods, are not allowed in taking part in domain-models?

6 March, 2008
Roman Eremin (DevExpress)
Roman Eremin (DevExpress)

> What do you mean with "Since interfaces cannot contain method definitions"?

No, I meant that interface cannot contain actual body of methods. AFAIR this is called "method definition" in contrast to "metod declaration" which is allowed in interface declaration.

6 March, 2008
Rinat Abdullin
Rinat Abdullin

Andreas,

I've missed that one.

Actually one can simply use extension methods that are part of the new C# syntax to define interface-wide methods. And you can use these features even for pure .NET 2.0 apps)

Rinat

6 March, 2008
Andreas Mummenhoff
Andreas Mummenhoff

>  AFAIR this is called "method definition" in contrast to "metod declaration"

You're right, but interfaces are always about "declaration" - why did you write "methods" and not "properties" or "functions" (they also cannot be defined)?

So if I understand you right, we could delete the word "methods" from this sentence without loosing any meaning?

6 March, 2008
Anonymous
How to inject ORM with some IoC? at Rinat Abdullin

Pingback from  How to inject ORM with some IoC? at Rinat Abdullin

7 March, 2008
Dan (DevExpress)
Dan (DevExpress)

Related conversations:

- "Doctors, Patients, Mechanics and Tax Evaders" at community.devexpress.com/.../doctors-patients-mechanics-and-tax-evaders.aspx

- "Question Details: inheritance" at www.devexpress.com/.../Q99121.aspx

- "Inheritance of persistent objects—conversion of basic objects" at community.devexpress.com/.../197004.aspx

- "Doctors and Patients: Specifying Derived Types" at community.devexpress.com/.../62872.aspx

- "XPO and inheritance hierarchy" at community.devexpress.com/.../60506.aspx

Thanks, Dan.

24 March, 2008
Dan (DevExpress)
Dan (DevExpress)

"Plugin type architecture with multiple modules" at community.devexpress.com/.../215314.aspx

Thanks, Dan.

1 April, 2008
Anonymous
eXpress App Framework Team

As some of you have noticed already, we have recently had to make a few changes to our plans for XAF

29 April, 2008
CA Team Member
CA Team Member

Hi,

Will this solution support persistent generic types? Now, there are some problems with it (see issues: www.devexpress.com/.../S18980.aspx and www.devexpress.com/.../AS10805.aspx).

Regards.

24 July, 2008
Roman Eremin (DevExpress)
Roman Eremin (DevExpress)

Well, this going to be a layer on the top of XPO, so when/if XPO will support generic persistent classes - we will support this too.

25 July, 2008
Anonymous
Basnight

"I want to be able to apply this model to any domain objects I want "... I need a module to create any domain objects. Please help me.

Thanks.

3 September, 2008
Anonymous
One does not have to be a good developer to make a lot of money | Rinat Abdullin

Pingback from  One does not have to be a good developer to make a lot of money | Rinat Abdullin

23 September, 2008
Anonymous
eXpress App Framework Team

I'm starting a series of posts on my blog to share our experience while designing the domain component

25 September, 2008
Anonymous
eXpress App Framework Team

In the first post of the series devoted to our new domain component (DC) technology , I tried to show

26 September, 2008
Anonymous
eXpress App Framework Team

This post is one in a series about our work on Domain Components (DC) framework and related component

1 October, 2008

Please login or register to post comments.