Hi guys

I took a look at your roadmap for 9.2 and noticed the following planned feature:

F583 Core: XPO-independent XAF-Core. F604 Core: XPO-independent modules.

I absolutely don't understand why you guys are actually considering this. I mean...

• XPO is your company's product. Why allow competition to step in? ( would Apple ever have sold one billion AppStore downloads if they had instead allowed developers to sell their apps on shareit or PayPal......?)
  
• XPO is fast, ensures excellent data integrity, has a low footprint, a low learning curve... etc. Most of the other frameworks I've tested are either plain crap or they have a learning curve which basically makes me think that hard-coded SQL statements would still be more comfortable (hi there, NHibernate!!).
  
• XPO can be extended directly by DevExpress as new requirements in XAF emerge.
  
• The XPO<->XAF combo is rock solid and stable in its core. Why put this aspect at risk?
  

I'm VERY WORRIED about two major issues if third party ORM frameworks are supported:

1. Will we loose speed and flexibility? Today we have the following layers: DB -> XPO -> XAF. Tomorrow we're going to have:

DB  -> ORM -> Generic XAF-ORM Interface -> XAF

This additional layer poses 3 main problems in my opinion:

A) Adding another abstraction layer usually reduces speed. And if an application has tens of thousands of objects, I don't think that's a good idea! The combo XAF<->XPO is what makes your product so unique (IMHO). How can you guarantee that speed won't decrease with this additional layer?

B) A generic interface means that the lowest common denominator of all ORM systems will dictate what's possible and what's not. How can you make sure that this won't slow down the overall development process of XAF? Just one example: As soon as XPO supports persistent interfaces, how would you go on supporting other ORM's that don't support persistent interfaces?

C) My biggest concern in this matter: Stability!!! I wouldn't want to sacrifice the excellent overall stability of XAF in its current form.

2. Will XPO customers be neglected? I assume your staff isn't growing proportionally with each supported ORM, is it? In other words, the same team who is now supporting XAF<->XPO issues (one-to-one relatioship ;-) ), will in the future be supporting XAF <--> any ORM (one-to very many relationship...). As a logical consequence, developers using XPO will find less know-how and resources in the official XAF support forums.

I'd appreciate some comments or statements on my concerns, especially from the devexpress team.

Thanks! Have a great weekend!

Daniel

It also makes more sense, if your building a framework you should allow the data layer to be customized.  Someone may prefer to use NHiberbate or some other form of ORM instead of XPO.  By making them separate the framework is more accepted for other developers that have invested in different ORMs.  I believe by default the XAF will use XPO, but developers will be allowed to choose a different ORM of their choice if they want to.  That makes a great framework. :)  Imagine if Microsoft only allowed IE to be installed on Windows since it is there browser, customers want to choose.  The same goes for XAF.

Similar to what Gary said...

If XPO is the only back-end for XAF, then all the responsibility for providing persistence functionality falls on DX.  If DX doesn't develop a feature, XAF users can't have that feature.

If that feature is a requirement, the developer can't use XAF.

If XAF is loosely coupled to the persistence layer, then DX is no longer the bottleneck for features.  The rest of the world can step in and complete the picture.

Best regards,

Adam Leffert

I'm actually with Daniel on this. Of course you can always argue about giving more choice to the XAF customer. But the way I see it, an XAF customer is a DX customer. And this also makes him an XPO customer. In plain language this means: When someone builds their first XAF test project, they get XPO as a persistence framework. Later when they decide to buy XAF I would say that they liked what they saw, otherwise they wouldn't pay money for it... right?

So how would someone who liked what they bought ever come into the situation of having to migrate an XAF project to a different persistence framework? I certainly don't see a reason for any of my XAF projects. And this is where the comparison to IE/Windows just doesn't work. A customer who buys Windows basically has no choice, because MS owns like 90% of the client market. But developers shopping for application frameworks have a huge selection out there... and once they've decided which one to buy, they have a really good reason for their choice. And the tight integration between XAF and XPO with all its advantages is a major part of what they were promised when they tried the bundle.

The argument of flexibility and loose coupling doesn't always count... otherwise you'd have to start supporting other IDE's, different ribbon bar components, maybe throw in a little PHP here and there...

I'd look at things the other way around: People who like other persistence frameworks (like NHibernate) better should go looking for application frameworks specifically made them. And if they don't find any, well then maybe that's an indication that they're using the wrong persistence framework!? They might want to consider switching to a persistence framework that's actually supported by developers who get paid real money for their hard work.

The tight coupling between XAF and XPO was a major decision factor when I bought XAF. So if down the road I'll get a "deprecated" flag on my CriteriaOperator.Parse(..) method just because NHibernate just so happens to support an entirely different syntax... well then I'll have go shopping for a different application framework.

Kind regards

Marco Kummer

I think what Marc Greiner said earlier is spot on ...

"These two roadmap points (F583 and F604) do not mean that XAF will necessarily at one point be independent from XPO and allow to interact with other ORMs.  It just means that there is going to be a better separation of concerns between XAF and XPO so that both layers can evolve more freely."  -- Marc Greiner

-- Alex Hoffman
expressapp.blogspot.com

Trevor: I think YOU are missing a big point! What makes you so sure that the way to success is to change the formula and integrate with numerous other solutions out there? As mentioned before, having a proprietory solution can have considerable advantages in ease of use and robustness. And those are two key factors for an express app framework; hence the name.

First I think we need to define what XAF wants to be and what not: It is a framework to develop solutions for small to medium businesses with minimum development and deployment effort. Such businesses usually have "limited" servers or maybe even no real server at all. So XAF/XPO with its 2 tier architecture perfectly steps in to cover the situation developers meet on site.

Will this still be true if XAF is opened up to any persistence layer? Does XAF need to have aspirations to compete with larger scale solutions like Oracle Forms  with 3 tier support? Or could it be the better strategy to continue filling the gap for small to medium sized solutions? Expansion would undoubtedly draw new customers to the platform! But this would also turn it into a new, different product when considering the definition above. And again: That is not what I bought and it would drive me away as I appreciate (and rely on) the small business approach. Making the persistence layer a separate part of the configuration and deployment process may just scratch the "express" part from the product's name - because those are things I don't have to think about today.

>Deprecation will happen anyway, what you will get is support to ensure compatibility with XPO and support to address breaking changes

So basically you're saying that things just have to be changed for the sake of it, regardless of whether they're working just great the way they are today? I don't understand this attitude. As a vendor of standard development components it is the task of DX to reduce the number of breaking changes to the bare minimum.

A note on 3-tier models: I'm aware of the advantages of this architecture. But working with XAF for a while I've come to an interesting conclusion: Decentralizing the business logic has some major advantages provided that you have a rock solid update management (which XAF fortunately provides the foundation for): Client machines nowadays are way underworked with their high performances. So it makes perfect sense to distribute the processing load to the clients while the server remains thin, hosting only a DB server. This reduces cost for the end customer by avoiding investments in server infrastructure and is therefore - once more - the perfect solution for small to medium businesses.

What comforts me is the fact that DX has always done a great job supporting their customers and finding innovative solutions. So for now I'm positive that my needs will still be covered in future versions.

Hi Daniel,

A very brief answer:

The main reason was Domain Components development - where views are tied to interfaces, not to XPO objects. 

As a side benefit - we will be able to construct views for any object, not just XPO objects.

Roman

Trevor, I fully understand and respect your requirements and the fact that you really hope for extended support for persistence frameworks. I really do. But while you'll be able to start blank projects with an open persistence layer support, I'm on the other end with several end customers running solutions with XAF/XPO. So if the scenarios you mentioned will be supported and they introduce major breaking changes, then how am I going to explain to my customers: "Hey, your next update will cost a lot more for the same functionality, because I had to overcome a lot of breaking changes in the underlying framework, in favor of customers with different requirements" ? I don't think they'll care, so I'll be the one paying for it with my own time.

So I'm not categorically rejecting your needs, I never said that. But I would definitely consider it to be unfair to make existing customers re-write major code blocks just so that new customers can benefit from an open persistence layer. And maybe if you had as much existing XAF/XPO codebase as me, you could relate to my point. (maybe you even do, I don't know)

Maybe a sort of outline about how DX wants to do this transition and how XPO customers will be affected would help take away my concerns. Maybe the whole thing is absolutely no big deal, but it would just help to know more. Right now, all I know is that XAF and XPO are tightly coupled, which means that de-coupling them would most likely introduce breaking changes.

I'm only medium familiar with EDI. But I don't understand how EDI would depend on the persistence layer used? (Persistence layers didn't even exist back when EDI was "invented") If I had to support it for one of my customers today, then I'd drop in a Windows service project with a reference to the XAF Base Module containing the business classes. This service would handle the data exchange on what ever communcations channel is required, and act on the business objects accordingly. I've done this before for other formats of data exchange (e.g. XML), and so far it works perfectly.

> Persistence is simply a storage mechanism where an application performs CRUD operations. Why is it that CRUD operations must be tied directly to XPO and XPO directly to XAF?

Well I'm not saying it has to be this way. I'm saying I like it the way it is now for several reasons: Performance, ease of configuration, etc. So can you guarantee that decoupling XPO from XAF won't affect data performance in a negative way? I believe it will, because introducing an additional abstraction layer always affects performance. And as you said yourself, all we gain from this decoupling is "simply a storage mechanism" which we already have with XPO, and which supports the majority of commonly used db engines today.

I totally agree with you on the security standpoint, though. A central service would make security enforcement a lot better. And as you suggested, it would be great to see this possibility created within XPO by DX.

Have a great weekend!

@Marco you have a strong point by your sayings, and they should be said at public so to Dx to remembers them when starting any transition.

But I also think that Dx guys are talanted and expiriend enough to create a bridge for any ORM with less impact as possible, of course zero impact is imposible and still we, Xpo people have to learn new stuff in order other ORM guys can work with Xaf. This is not bad in my opinion cause if Xaf community gets bigger everything around it will grow as well, so do we!!!

Tolis, I totally agree with you. Learning new things has always been part of the process. And when I'm starting new projects I like to seize the opportunity to learn new technologies as well.

But there's a clear difference between the addition of new features to extend and improve a product - and the alteration of existing features. The latter doesn't usually involve a beneficial learning process but simply means a lot of tedious work that none of our end customers wants to pay for. That's the kind of work that we don't grow by, and I think we all like to avoid it. So if XAF will offer great new enhancements I'll absolutely take advantage of them. On the other hand I wouldn't be pleased if I had to manually re-write say 5% of the old projects' code just to be able to re-compile them in the latest XAF version to finally achieve the same thing that had already worked before.

So I believe we're on the same track here.

That 5% remind me the days when Xaf was borned. That times the 5% was not a rare case at all. Thats why I spoke about Dx's experience in my previous post, cause I think that 5% nowdays does not apply at all. I am happy that we make a big post on this so Dx can see it and decide. And dont take me wrong if Dx can make it without 5% I would be much happier