Inside the Firewall Web Service - DTOs, BOs ???

Inside the Firewall Web Service - DTOs, BOs ???

Old forum URL: forums.lhotka.net/forums/t/3170.aspx


anon3141 posted on Wednesday, July 11, 2007

Hi All,

I'm relatively new to CSLA (4 months), and have a new project with a very short time frame.  Any help would be greatly appreciated.  My previous CSLA project persisted to XML, and was a straight forward win forms client.  From what I've read this isn't the best use of a web service, but it wasn't my decision to make.  This is a little different since the consumer won't be web forms, ASP, etc.

I've looked at some samples and gone over Ch10 & 11 in the C# 2005 BO book, and basically gotten myself more confused.  I could really use some guidance to get me unstuck. 


This is what needs to happen:
Our client wants a web service to access our database.
It will run totally inside their firewall for internal IT use only - no UDDI etc.
They want a simple mapping of one BO per table to insulate themselves from our DB schema.
The consumer of the web service, which the client will develop in C#, will most probably be a Windows Service which will push and pull data to our DB periodically throughout the day.
They will not be data binding to controls on a form.
The data will persist in a SQL Server DB.
The BOs will live on our application server.
And as best as I understand the web service will live on their IIS server.
The web service needs to return to the consumer a CSLA BO or list of BOs depending on the call.
For example, what they would like is:
WebService.Products[ID].ProductName, WebService.Products[ID].ProductName


Questions:
In this case does it make sense to simply return BOs?  What do the Web Methods look like?
When our client writes the consumer do they need a reference to the BOs?  How do they get it?
Are DTOs the best way to go?  What do the Web Methods need to look like?
What will they have to do to use whatever is returned by the web service?

I really need to know everything :), but any help to get me started in the right direction would help.
Sorry for such a long post, but I wanted to try and explain the situation.


Thanks!


RockfordLhotka replied on Wednesday, July 11, 2007

anon3141:

They want a simple mapping of one BO per table to insulate themselves from our DB schema.

That's funny! Smile [:)] I know I'm taking this wrong, but it brought a smile to my face to think about a bunch of entity objects, in lock-step with the shape of the database, insulating an app from the database. So when a table changes does the object not change? Hehe!

anon3141:

In this case does it make sense to simply return BOs?  What do the Web Methods look like?

Web services can't return business objects. They return data transfer objects, or at best entity objects.

The CSLA data portal uses some clever techniques to return actual BOs through a web service call, but honestly that doesn't fall anywhere within the spirit of web services...

anon3141:

When our client writes the consumer do they need a reference to the BOs?  How do they get it?
Are DTOs the best way to go?  What do the Web Methods need to look like?
What will they have to do to use whatever is returned by the web service?

You really have two choices: use the data portal to return real BOs, or use web services to return DTOs.

 

If you use the data portal, you can use the web service channel - thus living up to the "letter of the law" in that you are using "web services". But what you are really doing is returning actual BOs over a binary channel that is tunnelling through the web service. In this case both the client and server, by definition, would use CSLA objects exactly as discussed in the book (not chapter 11 - but chapters 6-10).

 

If you use raw web services, you will get back DTOs. In this case you can choose to implement either the client and/or the service using CSLA.

 

If you choose to implement the service using CSLA, then you should look at chapter 11. That's the purpose of that chapter: to show various ways you can use CSLA objects to construct the business layer behind your service "UI".

 

If you choose to implement the client using CSLA, then all you are doing is calling web services instead of stored procedures. I am serious: in this model, a web service is architecturally identical to a stored procedure. You'd just write your DataPortal_XZY methods to make web service calls rather than ADO.NET calls, and you'd run the data portal in local mode - and that's all there is to it.

Copyright (c) Marimer LLC