DevForce Community Forum : Is DevForce Future Proof?

Author: IdeaBlade
Subject: 158
Posted: 12-Jul-2007 at 12:26pm

This question has nothing to do with LINQ.

The author has posted a compound question, one that is a bit challenging to disentangle. I shall try briefly.

Your question is actually a multi-pronged question, each prong with its own sharp point. Let me see what I can do with it.

"Program to an interface, not an implementation"

That's a great aphorism. How should it guide us?

I assume that you are not expecting DevForce to provide interfaces for everything; no one does that. I think the question can be rephrased as

"Why doesn't the Object Mapper generate interfaces for DevForce business object classes?"

We've wrestled with this one over the years ... and it never quite goes away. There is at least one scenario where interfaces would be very useful indeed.

[aside: They might be useful for bridging two business models. Consider two models - which means two separate assemblies. An entity in one assembly must refer to an entity in the other and vice versa. Two .NET assemblies cannot refer to each other. An interface in a third project, referenced by both, would facilitate an arrangement in which the entities in separate assemblies could access each other through their mutual interfaces. In practice, few of our customers actually need multiple models with bi-directional entity references. We offer a prescription for this when and if you need it.]

On the other hand, every design pattern has a cost and we've concluded that the cost is to high for our customers

We are already generating two class files per business object entity (the final class and the DataRow class); another would add to the file management burden.
Interfaces are supposed to be small (3 to 10 members tops); even the most simple business object entity would have an enormous number of members.
One creates an interface in contemplation of multiple implementations. We can't think of a good reason to have multiple implementations of a business object and crafting a second implementation that satisfied the huge interface of a DevForce entity would be an enormous challenge.
Developers are expected to add custom members to their final classes - lots of them; if there were an interface, they would have to remember to extend that as well.
Extending an interface breaks all other implementations. I would be in a tough spot if I had to enrich the business logic in my entity ... and carry that through to the interface.
We'd be asking developers to manage and evolve an interface file that they almost never use; this is contrary to agile principles.

These are just a few of the impediments to generating an interface for every entity class. So, although it would be easy to generate an interface - a piece of cake really - we have held off doing so until there is a compelling use case.

What if I need an interface (e.g., for the cross model scenario)? It is not hard to add an interface by hand later as long as I don't make a habit of it. Such a custom interface can be nice and short, providing just the API that is required to meet its purpose.

Observe also that DevForce entities derive from abstract classes. Abstract classes provide a stronger and more flexible "contract" than interfaces and are almost always preferred to interfaces (see "Framework Design Guidelines" by Cwalina, et. al).

"Microsoft appears to be taking [interfaces] on wholeheartedly with WCF"

Microsoft has always made judicious use of interfaces. So has IdeaBlade (see IEntityQuery for example). But Microsoft doesn't use them everywhere. You don't see an "IControl" for example. You won't find them everywhere in WCF or WPF either. Interfaces appear where there is reasonable expectation that some external party will provide an implementation of the interface. That situation just doesn't seem to apply to business objects.

"I don't want to be locked in"

A noble goal and we do our best to facilitate that goal through our layered architecture.

Consider, for example, the separation of the final class from the generated class. You put all of your proprietary, custom business logic into the final class. Suppose some day, you decide to leave the DevForce community and strike out on your own. You could generate your own equivalent of our DataRow classes and make your final classes inherit from them. Your custom work survives the switch. The UI layer only talks to your final classes so it knows nothing of this change.

Suppose you have your own notion of an Entity super class on which to rest all of your business object classes. It is a trivial matter for DevForce to generate a base class supporting your object model. You take this base class, break its inheritance from our Ideablade.Persistence.Entity class, and put your own uber-class in its place. Now you can keep both your custom final classes and the DevForce generated DataRow classes. The UI layer need not know about this change either.

Our approach assumes that a manager class instance provides the persistence operations essential to an object-oriented persistence layer. This is the PersistenceManager in DevForce. To my knowledge, every object persistence product on the market has a similar construct (albeit with much different API and capabilities). You could replace our PM with something you wrote that adapted an alternative manager to the PersistenceManager API. Call it "PersistenceManager" and the resulting impact on your UI layer should be comparatively small.

I don't mean to suggest that any of this would be a breeze. But it would be possible precisely because we have such a well layered and well abstracted architecture.

Interfaces do not provide the reassurance you seek.

DefForce delivers an enormous amount of functionality. If you want what DevForce offers AND you want to keep your options open, you'll want to find alternatives that offer comparable range and power. An interface - if it existed - would prescribe the API. It defines the so-called contract. If you decide DevForce should no longer fulfill that contract, you'd have to find someone (something) that can. The contract itself is useless unless and until you can find a party to sign up for it.

Keeping with the power analogy, suppose we decided that we didn't want to use energy from our local utility giant. The interface is simple (110v, 50hz). Our challenge is finding an alternative source of energy that is reliable and adequate. That's not too hard if our needs are limited. It's a different story if we have to provide 24/7 power to industrial plants distributed over a wide geography. We won't know if we made a big mistake until the day we switch over.

You face a similar challenge if you want to keep a DevForce alternative waiting in the wings.

Of course you can always decide that you don't want the DevForce capabilities in the first place. Again, our interfaces (or lack of them) have no bearing on this choice.

What if IdeaBlade goes out of business?

Always a good question.

Would you feel safer if you had the DevForce source code? We offer several flavors of source code access; our sales team would be happy to talk to you about these options.

Maybe you are just uncomfortable relying on a single vendor. As with any threat, you might want to weigh the alternatives. One such alternative: "I'll write the .NET application infrastructure myself".

You might ask yourself:

How long will that take? Can I put a cost on the effort or is my labor free?
Can my client or manager wait until I'm "done" before I start building the application itself? Are there lost opportunity costs?
Who will document my infrastructure for other developers and at what cost?
Who will train other developers and at what cost?
Who provides the support? Who fixes bugs? At what cost?
Who besides me can maintain it and enhance it? What happens if I leave the company?
Do I know enough to build what IdeaBlade has built over the last four years?
What happens when Microsoft introduces the next version of .NET?

Many of our customers can't answer these questions with any precision. Predictability is important to them and such an inventory of unknowns introduces a degree of uncertainty they can't afford.

Some customers feel that they can measure these risks and assign the costs; they quickly conclude that DevForce is a bargain.

In our view, build-it-yourself is almost always the wrong choice. A better question is: "do I go with IdeaBlade and DevForce or do I go with a different product?"

That's a question for another day. I mention it only to suggest that "interfaces" - their presence or absence - are of little help in answering that question. No one really wants to swap out their application infrastructure anyway. They want features, performance, support and ... yes ... vendor stability. I think we're extremely competitve across the board on these crucial criteria.

You started with a technical question - where are the interfaces? - and suggested there were business implications to the question. I trust that you found my combination of technical and business answers to have been responsive and not just some DevForce sales pitch.

Of course I hope that you (and other readers) will decide to join the DevForce development community (and that IS my sales pitch).

]]>