If you are already going to use WCF to retrieve data like e.g. smart client
from the server. Then using messaging is almost the same as calling the
service. But async and without complexities of dealing with async
explicitly. Send a message. Receive another one. Block in between if you
want request/reply semantics.
I'd go with coarse grained messages going out of the MVC client. I.e. send
message like "NeedDataForUserProfileScreen" & "reply" is
"DataForUserProfileScreen" with everything you need to render that.

How you handle that NeedDataForUserProfileScreen message on the "server" is
another matter.

On Wed, Jun 17, 2009 at 1:17 AM, Simone Busoli <[email protected]>wrote:

> I'm not sure I follow. How would you perform data access with messaging? At
> least it's not a scenario I ever figured. Would you send a message saying
> that you need some data and you get a reply containing the data?
>
>
> On Tue, Jun 16, 2009 at 21:25, Craig Neuwirt <[email protected]> wrote:
>
>> I have an ASP.NET MVC application full of ActiveRecord databinding and
>> Finders (Specifications) for data access.   WCF is used to communication
>> with services.   I will no longer have access to the database in the MVC
>> Application layer so my plan is too replace all WCF with Rhino ESB.
>>  However, I am not sure what the best approach to replace the AR DataBinding
>> and other data access.  Should you use messages for that too or stay with a
>> more traditional service to handle data access.  I definitely don't want a
>> bunch of distributed repositories with an ever increasing number of methods
>> to retrieve different pieces of data.
>> Any ideas or suggestions would be appreciated.
>>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Rhino Tools Dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/rhino-tools-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to