Microsoft .NET RIA Services and DevForce
The Vision of .NET RIA Services
It is especially hard to move data across the web in a Silverlight business application.
Microsoft is working to create an ecosystem around this specific challenge and has
announced RIA Services which 'provides a pattern to write application logic' in
a modern RIA.
Ecosystem for Data Services
You might think of DevForce in the same way that you think of third-party control
vendors: we target a common problem that Microsoft also addresses; but we are dedicated
to that problem - it is our only business - and we deliver the additional benefits
that yield large, near-term returns on investment for customers who care about the
cost of development, maintenance, quality, and time-to-market.
Alignment with RIA Services
DevForce shares with RIA Services the “one model” perspective on Silverlight business
application architectures. In this view, the authors of a business application are
responsible for a single application that just happens to be deployed over the net.
This happenstance means there must be separate components executing on a server
and on the Silverlight client and these components must communicate somehow. But
from the developer point of view, there is one application with a single domain
model. The challenges of distributing that model are implementation details we’d
like our infrastructure to handle for us.
DevForce and RIA Services share a similar vision of the infrastructure and development
techniques that support this perspective. While we differ in implementation details,
what we have in common means that DevForce can offer a “RIA Services API”. Properly
layered applications will be able to write to this API as if RIA Services were under
the hood. We are moving toward this goal, subject to forthcoming changes in the
RIA Services APIs.
We do not expect developers to swap out DevForce for RIA Services nor would we think
that you could convert from one to the other overnight. We do believe that enterprise
customers will take comfort in knowing that they have a RIA Services option and
that developers who know RIA Services can adapt easily to DevForce.
Why DevForce?
DevForce is mature
Yes, we are evolving it rapidly to keep up with changes to Silverlight and to further our
POCO initiative. But we’re extending an existing product whose fundamentals are in place.
RIA Services is in flux with some fundamental design and implementation decisions undecided; see,
for example, the intention to move to ADO.NET Data Services as the underlying protocol.
Experience matters
DevForce is version 5 software. N-tier application development is not something you understand by intuition.
You learn it painfully over the course of many years. We have a track record. We released the first
version of our .NET product for distributed persistence and business logic development back in 2001.
We have many real-world customers who’ve released critical applications with DevForce inside.
We know what they are trying to do. We’ve helped them build these applications.
We’ve supported them. We’ve learned many painful lessons. We’ve had almost no turn-over
so our developers and staff have been in these trenches for eight years or more.
Best Deal on the Market
DevForce isn't free. Neither is RIA Services – see
Ward Bell’s blog on the subject. As Ward points out your investment in DevForce
starts making you money after only 28 hours in added value.
DevForce supports Silverlight, WPF, Windows Forms, and ASP clients today
We’re ready if you have an application which needs to support multiple clients;
such support in RIA Services is more than a year out.
More loosely coupled model development
You have substantial freedom to locate you domain model classes in the separate
projects of your choosing. In a typical solution, there is an Entity Framework model
project, a DevForce server-side model project, and a Silverlight client-model project.
Both client- and server-side model classes are identical … unless and to the degree
that you choose to make them different. DevForce maintains continuity of the models
when your object mapping changes (e.g., as a result of schema changes). It stays
out of the picture as you enrich your entities with custom business logic.
RIA Services today prescribes exactly where your classes reside and how server and
client projects are related. It is hyper-active in monitoring changes to your server-side
model. Every change you make – not just database schema and mapping changes – every
change causes regeneration of the corresponding Silverlight client classes. These
classes look sort of like their server-side counterparts...but not exactly.
DevForce Features
Client-side LINQ
Any LINQ query that would run on the server (e.g., Entity Framework LINQ query)
can be composed and launched from a Silverlight client.
This is not a 'coolness' feature. Yes, with RIA Services you can write a LINQ query
on the server and expose it back on the client as a custom service method. But there
are consequences. When you need a query on the client, you must update the server-side
code and redeploy to your server(s). If you need a parameterized query on the client
– as when the user specifies multiple filtering criteria – you must roll your own
client-side query protocol... essentially defeating LINQ's advantage as a common
query specification format.
RIA Services acknowledges the problem by offering limited LINQ-ish filtering of
its own. They know they can't require developers to write every query as a service
method. And if it is essential to offer a limited form of client-side, LINQ-based
filtering, why stop short of a complete client LINQ solution?
Client-side LINQ shines in combination with DevForce caching and offline support.
I can write a LINQ query once, knowing it will execute on the client when a server
request is redundant or impossible.
Client-side query-able cache
Eliminates unnecessary trips to the server and simplifies development of synchronous
user experiences in an asynchronous Silverlight world.
The first point speaks to the responsiveness of your UI which is threatened by the
long latency of server requests... and speaks to scalability which is threatened
by pressure on the network, middle-tier, and database from clamoring remote clients.
The second point will seem mysterious only until you try writing a UI that copes
with the uncertain availability of data you need to display now.
Offline
A DevForce application can continue to function productively even when the server
connection is lost. It can continue to query against its cache of previously retrieved
and newly created entities. You can modify and schedule deletes. You can add more
new entities. And you can save them transactionally when the connection is restored.
With Silverlight 3's out-of-browser support your application can launch and run
effectively while completely disconnected by leveraging DevForce's ability to save
and re-load cached entities in local isolated storage. This is ideal for 'traveling
salesman' and 'remote field rep' scenarios.
Message transport via WCF Services
We exchange information with our middle tier 'BOS' using WCF Services. WCF Services
are more efficient than REST. Binary serialization reduces the payload size. The
usual objection to WCF Services... that it is more complicated... is irrelevant to
you because we do the heavy lifting; your application requires minimal configuration
and no attention to the complexity and nuances of WCF.
POCO support
While Entity Framework is the primary entity provider in most DevForce applications,
you can also query and cache POCO classes from any data source returning IEnumerable
Full inheritance support
DevForce supports domain object class hierarchies so you can put common logic in
base classes where it belongs. DevForce supports polymorphic queries; with a single
query on a base type I can retrieve a single collection of diverse derived types
as when a request for 'Produce' returns a list of 'Apples', 'Oranges', and 'Potatoes'.
Validation
DevForce supports all of the RIA Services / Silverlight 3 validation attributes
– you apply them exactly as you would in RIA Services. Our Object Mapper can generate
some of these attributes for you... the ones that are 'obvious' from the database
schema... if you want it to.
You can blend this SL3 validation approach with our own validation facilities which
are richer in several respects. They can be defined and applied to any class without
resort to attributes. They can be applied to any property anywhere in a class hierarchy.
You can programmatically add and remove validations, client- or server-side, based
on dynamically determined information such as user role. You have complete control
over the validation context which means you can respond differently depending upon
when and where the validations occur. You decide when validation occurs and how
it proceeds. You can control the order of validations, skip validations, bail out
when there are too many errors, etc.
Client code generation
RIA Services generates client domain object classes with simple property implementations
that support limited customization of setters only. You can introduce any kind of
behavior you need – for both getters and setters – because properties of DevForce
generated classes tie into our dynamic Aspect Oriented Programming (AOP) engine;
that engine enables programmatic injection of your custom concerns into both getters
and setters at any level of the object class hierarchy.
Lifecycle events
DevForce offers numerous interception points throughout the domain object lifecycle.
There are pre- and post- opportunities – both on client and server – to detect and
respond to queries, entity creation, modifications, deletions, saves, login/logout,
application and server start/stop, connectivity start/stop, etc.
Integrated authentication / authorization
We’ve always supported custom login plug-ins that adhere to the standard .NET IPrincipal
protocol; alternatively you can enable ASP.NET security features with some simple configuration.
Entity ID generation
New entities need new Ids. RIA Services doesn’t address this issue; it defers to
the serve-side data provider. If you rely on GUIDs or identity columns, you're probably
ok. If you need custom id generation, such as a database table holding id counters,
you could be in trouble without DevForce... especially in offline scenarios.
Logging
DevForce has an intrinsic logging capability that captures many of your application
activities automatically...activities such as persistence operations (insert/update/delete),
login, configuration discovery, assembly discovery, and middle-tier exceptions.
You can supplement these entries with custom log messages that interleave user behaviors
with DevForce and application responses. You can record log entries as they happen
because DevForce will publish log activity on a secure port of your choosing; we
offer an out of the box LogViewer... or you can subscribe with your own custom monitor.
|