We’re doing a data integration project between a MS Sql Server database and a Microsoft CRM system (through its web services).

We’re trying to build a “service” layer on top of the database. The design of our current solution is to use web services for CRUD, with xml being the format of data.

Views are created to consolidate related tables into one entity, and we query these views, using the “SELECT * FROM someview ” + “For XML” to generated xml that will be returned from our web services.

For update we’re trying to use the same approach – using SQL XML to map updates views, we have “instead of” triggers defined on top of these views, and in these “instead of” triggers we update the underlying tables.

The views/triggers are generated by tools so don’t be too concerned with coding efficiency here…

what do you think if we use WCF data Provider to publish a enterprise data model (essentially DTOs) ? p.s., we don’t have a BL layer for now, it’s all in the stored procedures!!!

What’s your opinion on this / any better design? much appreciated!

i agree with u.

RIA Services doesn’t change my opinion about this at all. The more you share between client and server, the worse off you’ll be. It’s really as simple as that.

And yes, it could lead to a lot of DTO’s. And yes, you have to write them by hand. People quickly say that it’s a lot of work, but seriously, if that takes up too much of your time than you’ve got bigger problems to worry about. And yes, you can have multiple DTO types which essentially all ‘show’ data from the same entity, but in different ways. But they all will be used in the most optimal manner… the one-size-fits-all approach simply doesn’t hold up for long.

As for the ResultTransformer… you can use projections in your NHibernate Criterias and then let NHibernate hydrate your DTOs directly through the ResultTransformer, based on the projections. A quick google search should tell you more.

Thanks in advance .

my only requirement is basically that databinding can _never_ trigger an automatic service call or database roundtrip… that’s pretty much it as far as i care about it

You’d probably use the data from the DTO’s, or even the DTO’s themselve in the ViewModel but a ViewModel itself is in no way a DTO IMHO

yeah, we occasionally map views with NHibernate as well and in some cases even use stored procedures for really complex queries

We actually considered doing something like you mention, where we create NHibernate mappings directly to the view models, but because of various reasons we chose to change our domain model a bit and denormalize some of the data. Not sure what the effect was, since I’m not working on that part of the system at the moment. We also discussed persistent viewmodels, or rather persisten reportmodels, since it is our big reports that eat up most of the resources. The app is quite reporting heavy.

If one choses to use some kind of persistent viewmodels, you could do the updates to the viewmodels async, so they’ll be eventually consistent. I guess more in line with the whole CQRS thinking. Depends on your needs I guess.

Btw, I’d also chose read performance in most of my apps any day of the week. However, some apps will be more read heavy, and such a solution would not be as effective.

“Would you go ahead and duplicate the rules on the front end? Or maybe create some sort of helper class that performs the calcs, which both the VMs and entities could call? In most cases I also need to validate the numbers before persisting them, and it would essentially be using the same formula to make sure the numbers are correct.”

sort of depends on the actual calculation… if it’s a very easy one or one that is highly unlikely to ever change, i’d just duplicate it to be honest. sure, some people would call me heretic for that but a little bit of pragmatism never hurt anybody. If it’s a tough calculation, i’d either go with the helper class, or just making it a server-side only thing. You could trigger the request to calculate the value asynchronously when the user inputs both required fields and then just update the calculated value when the result is retrieved. then you can reuse the same logic when you’re performing your final server-side validation as well.

@Henning

i’d rather not sacrifice read-performance… people’s impression of a system’s responsiveness is largely based on read-performance. That writes are a bit slower than reads is somewhat more easily acceptable to them “because the system is working!” other than “it’s just supposed to show me data!” during reads

@Dan Jensen,
In that case you’d want to extract the calculation into a “Domain service” and inject the calculation class into your entity via Double Dispatch, and into your MVC controller (or whatever else you use). Remember to use interfaces when injecting and not the actual implementation of the calculation!!