WPF/Silverlight enterprise application architecture.. what do you do?

Question

I've been wondering what lives in the community for quite some time now; I'm talking about big, business-oriented WPF/Silverlight enterprise applications.

Theoretically, there are different models at play:

• Data Model (typically, linked to your db tables, Edmx/NHibarnate/.. mapped entities)
• Business Model (classes containing actual business logic)
• Transfer Model (classes (dto's) exposed to the outside world/client)
• View Model (classes to which your actual views bind)

It's crystal clear that this separation has it's obvious advantages; But does it work in real life? Is it a maintenance nightmare?

So what do you do? In practice, do you use different class models for all of these models? I've seen a lot of variations on this, for instance:

• Data Model = Business Model: Data Model implemented code first (as POCO's), and used as business model with business logic on it as well
• Business Model = Transfer Model = View Model: the business model is exposed as such to the client; No mapping to DTO's, .. takes place. The view binds directly to this Business Model
• Silverlight RIA Services, out of the box, with Data Model exposed: Data Model = Business Model = Transfer Model. And sometimes even Transfer Model = View Model.
• ..

I know that the "it depends" answer is in place here; But on what does it depend then; Which approaches have you used, and how do you look back on it?

Thanks for sharing,

Regards, Koen

Answer 1

Good question. I've never coded anything truly enterprisey so my experience is limited but I'll kick off.

My current (WPF/WCF) project uses Data Model = Business Model = Transfer Model = View Model! There is no DB backend, so the "data model" is effectively business objects serialised to XML.

I played with DTO's but rapidly found the housekeeping arduous in the extreme, and the ever present premature optimiser in me disliked the unnecessary copying involved. This may yet come back to bite me (for instance comms serialisation sometimes has different needs than persistence serialisation), but so far it's not been much of a problem.

Both my business objects and view objects required push notification of value changes, so it made sense to implement them using the same method (INotifyPropertyChanged). This has the nice side effect that my business objects can be directly bound to within WPF views, although using MVVM means the ViewModel can easily provide wrappers if needs be.

So far I haven't hit any major snags, and having one set of objects to maintain keeps things nice and simple. I dread to think how big this project would be if I split out all four "models".

I can certainly see the benefits of having separate objects, but to me until it actually becomes a problem it seems wasted effort and complication.

As I said though, this is all fairly small scale, designed to run on a few 10's of PCs. I'd be interested to read other responses from genuine enterprise developers.