[RESOLVED] Problems when returning objects from webservice

I have a serializable object called "users" which is a collection of "user" objects.

The usercollection has a method called GetDistinct, which returns a distinct collection of users. Now the problem is that when I call my webservice

dim proxy as new mywebservice

dim usercol as usercollection = proxy.GetAllUsers <---- this is not working


Because it looks like the returning object from the webservice is of a type in the webservice namespace, but the object im defining on the client "usercol" is also a usercollection but from another namespace(my business objects). Therefor I get an error :( And I cant really use the object in the webservice namespace because it doesnt contain the method GetDistinct

What am I mssing here??!?!?
/Henrik

I started to think about this some more... and I could think of no other solution than to edit the reference.vb file and include the businessobjects namespace there... then at least they talk about the same objects.

Or use .net remoting.

Its very annoying problem

/henrik

It is not necessary to have a custom object returned to your client if the client knows about it already. What I mean is, in an Entity-Relationship model, you don't want the web service to know about the Users collection. It shouldn't have to know about it in fact.

I'd make the web service return a dataset with the details (property values) for each user, then make the Entity class loop through the dataset, create the users collection, and then send it on to the client.

Hi!

Your above post is very interesting. Im currently starting on a new project, and it will be developed in asp.net 2.0. Here is the deal:

We will build part1 of a sales app that will be used by our suppliers, purchasers, warehouse workers etc... it will consist of an internet part and an intranet part.

This app share the same database. It will be a 100 % web app, no winforms or handheld at the moment. The problem we are facing now is how to make the tier design.

Here is the initial plan.

DATA SOURCE (oracle)--->DataAccessor--typedDataset-->ServiceProvicer-->asp.net 2.0 app


DATASOURCE
This is the database, all sql code will be in stored procedures as well as some business logic.

DataAccessor
This is a class library which uses a standard component to call stored procedures and return the resultsets as typed datasets.
Methods will look like GetSuppliersBySite(byval siteCode) as SupplierDataSet

ServiceProvicer
This is the webservice which stores ALL the methods for all the parts of this big app. For our part 1 perhaps we add 16 methods. Then part 2 adds perhaps 20 methods, part 3 adds 35 methods etc...
This is the part I could sure need some advice on. The methods should look the same as above GetSuppliersBySite(byval siteCode) as SupplierDataSet

asp.net 2.0 app
This is the web application. It uses ONLY the webservice serviceprovider facade to fetch data and bind it to the controls.


Well there you have it... do you experienced developers/architects see any BIG problems with this design, anything you would do different? Please tell me :)

kind regards
Henrik

UI -> BusinessObjects -> WebService -> DataAccessLayer -> DataSource

(Do you need this explained to you?)

That's how I'd reccommend it be done anyways, for a large app. If it's not a large app, your approach seems fine.

Hi and thanks for the reply.

yeah this is a rather large app, when it goes online it will be used by at least 4000 suppliers world wide... plus all the intranet users.


Your approach is interesting

UI -> BusinessObjects -> WebService -> DataAccessLayer -> DataSource

Does this mean that I will be working with classes on the client (asp.net) side of the webservice facade? If that is the case, how do you recommend these businessobjects to be realized? As custom classes or typed datasets?

So if I understand it correctly, you want the clients to have a full library of businessobjects, and these objects invoke webservice methods?

For example: A supplier want to create an invoice!

He goes to invoice.aspx, fill in a form, when he clicks "invoice" an invoice business object is created, populated with data and then the .Invoice() method is invoked on the invoice object which calls a

webservice "invoiceService.asmx" that has a method called DoInvoicing(byval inv as Invoice)

Is this correct?

if yes, then how to handle fetching of data from database to client. Say I want to populate a datagrid with all the orders for a specific supplier. I have a supplierService.asmx that has a method GetOrdersBySupplier(byval supplNo as string) as dataset

When I move to the page OrderLines.aspx I create a new orderLineCollection object, invoke its Load() method which calls the webservice. Then in return I get a dataset which the orderlinecollection uses to populate itself, then it disposes the dataset. Finally the orderlinecollection binds to the dataset...


Do I understand this correctly? If not, please correct me...

kind regards
Henrik

Hi!

I was just wondering, if I grasped your comments correctly?

And then there is this about the business objects... should they only hold the business logic, or should they have the capailities of creating themselves using information from database? Like

VB Code:

public class Person
 
public sub new()
end sub
 
public sub new(byval id as string)
me.GetPerson(id)
protected sub GetPerson(byval id as int32)
'call the database to get a datatable with one row
and fill this object with the information
end sub
 
end class

OR

should the business objects only contain information, but rely on other classes to marshal them (updating, deleting, creating etc). That should mean that the webservice should be able to fully marshal custom business objects, which it can't :( For example a personcollection that implements collectionbase will be converted to a Person array when passed through the webservice. That means that on the client i have the Person() and on the other side of the webservice, in teh wrapper class or dataaccessor class I have a personcollection... This is bad... how can I avoid this?

/Henrik
kind regards
Henrik

Sorry for the delay, I have been very busy contemplating important philosophical issues such as "What's that gray thing on my toenail?"

Quote:

---

Originally Posted by MrNorth

Does this mean that I will be working with classes on the client (asp.net) side of the webservice facade? If that is the case, how do you recommend these businessobjects to be realized? As custom classes or typed datasets?

---

Now, I am not forcing this architecture on you, I am suggesting it because I have worked on something quite similar to what you're working on, and I determined that this was the best way to go about it. The reason, let me reiterate, was to allow for separation of front end from back end. The entity-relationship model will let me do that because the front-end client will have to follow a set of rules when working with whatever data my web service provides.

For instance, instead of having my web service return an exception due to bad data being inputted, I would rather my business layer returned that exception, rather than the web service which is only facilitating my transactions.

To answer your question, yes, custom classes. Regular old classes with properties and methods and collections.

Quote:

---

So if I understand it correctly, you want the clients to have a full library of businessobjects, and these objects invoke webservice methods?

For example: A supplier want to create an invoice!

He goes to invoice.aspx, fill in a form, when he clicks "invoice" an invoice business object is created, populated with data and then the .Invoice() method is invoked on the invoice object which calls a

webservice "invoiceService.asmx" that has a method called DoInvoicing(byval inv as Invoice)

Is this correct?

---

Yes. Quite right. In fact, the argument (byval Inv as Invoice) wouldn't be necessary since a single Invoice class represents a single Invoice object. If you see a circumstance in which you have many invoices or lineitems being updated together, you can use an Invoices class, which has a collection of Invoice objects, and its own methods which can update/validate/whatever individual invoices if you like.

Quote:

---

if yes, then how to handle fetching of data from database to client. Say I want to populate a datagrid with all the orders for a specific supplier. I have a supplierService.asmx that has a method GetOrdersBySupplier(byval supplNo as string) as dataset

When I move to the page OrderLines.aspx I create a new orderLineCollection object, invoke its Load() method which calls the webservice. Then in return I get a dataset which the orderlinecollection uses to populate itself, then it disposes the dataset. Finally the orderlinecollection binds to the dataset...

---

The orderlinecollection is passed to the asp.net page, the asp.net page can then use the orderlinecollection to bind a datagrid, or populate a few textboxes, a repeater, the presentation logic is up to the developer/you.

Quote:

---

Originally Posted by MrNorth

Hi!

I was just wondering, if I grasped your comments correctly?

And then there is this about the business objects... should they only hold the business logic, or should they have the capailities of creating themselves using information from database? Like

VB Code:

public class Person
 
public sub new()
end sub
 
public sub new(byval id as string)
me.GetPerson(id)
protected sub GetPerson(byval id as int32)
'call the database to get a datatable with one row
and fill this object with the information
end sub
 
end class

OR

should the business objects only contain information, but rely on other classes to marshal them (updating, deleting, creating etc). That should mean that the webservice should be able to fully marshal custom business objects, which it can't :( For example a personcollection that implements collectionbase will be converted to a Person array when passed through the webservice. That means that on the client i have the Person() and on the other side of the webservice, in teh wrapper class or dataaccessor class I have a personcollection... This is bad... how can I avoid this?

/Henrik
kind regards
Henrik

---

You ought to only create the business objects that are going to be used by the application. You don't need to create them dynamically. Keep it simple.

I don't understand what your'e talking about in the second part... can you explain that one again?

I also want to add that if you like, you can also allow the web services to return your custom classes rather than datasets. Remember, everything including and ahead of the web service is the back end, while anything could be in the front end.

Hi!

Thanks for the reply

What I mean is that the business objects in this kind of application shouldnt have any CRUD methods, but should rather be used as a mean of "boxing" the information, like a basic struct. Why?? Well, because you face a number of difficulties if you want to marshal business objects from one app domain to another... Lets say we have this scenario:

ASP.NET web app on server A

ASP.NET webservice order-provider on server B

The DAL and the business objects are deployed on both server A and B


If you press a button in the webapp to save an order, you create a new order object on server A, now you need to marshal it to server B to persist it to the data layer. This wont work because the Webservice isnt't familiar with this object, it only know the objects in the reference.vb file. And if you try to cast it you will get an error...

When I have worked with custom objects and webservices I have had nothing but trouble... But Generics seem to work better marshaling from one app domain to another through webservices...

/Henrik