Our main web app is built to deliver product information from manufacturers to sales reps. To over simplify things, it's a way to enter product information electronically and deliver it to independant sales reps to replace paper catalogs and price sheets.
We have so much code written in CSLA 1.5 that we haven't moved up to the newer version yet so our objects for this application are still 1.5 (in C#). Our main app is an ASP.NET app with one half being used by manufacturers to enter data and the other used by the reps to search the product information and create sales proposals.
The problem:
Our Product object is enormous. We have over 300 properties, actual set/get properties and not fields. I know, I know, everyone's first comment will be about the size of our object. However, there really are that many pieces of information about each product. Shipping fields, dimensions fields, sales policies, warranty information, return policies, several different contacts for each manufacturer, and on and on and on.
We have so many fields that we have metadata tables that hold a record for each field describing the field and then we put the fields into "Field Groups" so the users can see small portions of the data, grouped logically, for data entry. They select a "Field Group" from a drop down and we dynmically create a GridView at runtime (using the metadata objects) and bind it to our giant Product object which has all the properties. Now we can't create objects for each Field Group because they change a lot and our users can even create their own "Custom Field Groups" using a field picker.
Anyway, we are being asked to create a Web Service to provide the same functionlity as our Search Page so users can incorporate it into their own sites and apps. We'll be passing in authentication information (in the SOAP header) and our parameters will be the search criteria (TextSearch, PriceFrom, PriceTo, PriceType, Categories - ArrayList, Brands - ArrayList, MarginFrom, MarginTo, Status, ManufCountry).
Our last parameter is the problem, it's going to be FieldGroupID. So the parameter list above dictates which products are returned, but the FieldGroupID dictates which of our 300 product fields will be returned. They'll be able to administrate Field Groups on our website using the "Field Picker" and then they can pass in the ID of that FieldGroup as a parameter of our web service and just get those fields returned.
I'm looking for some advice on:
How I should return this data? This is our first web service and I'm reading up but I want to keep as standardized as possible. I was going to return a DataSet but then I read that I shouldn't user a strictly .NET type object. Any suggestions.
How do I handle that in the object? For our current search form we have a fixed number of fields. We return the same fields each time so I have a collection ProductSearchResults which holds ProductSearchResultsInfo objects. However, for the web service that class would be different every time, depending on the field group id passed in. In our data grids we just bind to the entire gigantic product object. I can't give the users back all that data and we wouldn't want them to have access to all that anyway.
So how do I create a dynamic object like that? And how should I return that in a web service?
Thanks guys... larry
This is why I often use "product" as an example when speaking about objects. Many times a "product" really does have a massive number of properties - you aren't alone in that by any means.
And your use of meta-objects to shape the data for the UI is perfectly wonderful. Technically I'd say that those objects are part of the UI layer, and as long as that distinction is made then it is a great idea. I use UI objects quite frequently to reshape or enhance UI data manipulation.
A web service is just another type of UI, and so using a similar UI-object concept there makes a lot of sense too.
Unfortunately, web services were created by the people who brought you COM - and so the technology is designed around a rigid contract worldview. That's problematic for dynamic data, but you can overcome it.
You are right to avoid the DataSet. The only things you should be returning from a web service (if you want interop or SOA) are serialized data transfer objects (DTOs). I show some simple examples of this in Chapter 11, but obviously not nearly as dynamic as what you are describing.
So your challenge, should you choose to accept it (and I assume you really have no choice ![Smile [:)]](/emoticons/emotion-1.gif)
), is to define a rigid contract that provides for dynamic behavior.
That's not terribly hard though. You could return an array of name/value pairs.
While it is true that web services can't handle a Dictionary or Hashtable, they can handle arrays. And the array can be of a complex type (DTO) that contains two properties: name and value. Your FieldGroupId would merely specify a specific set of properties to return, and you'd populate your array with those specific property values (and the property names of course).
The WSDL contract can remain rigid: it says you are going to return an array of NameValueData items. But what you put into that array is up to you.
Copyright (c) Marimer LLC