a quick design question

[brianlanning]

I have a class that represents a business object. Currently, this
class exists as a vb6 "class" which will be ported to .net. The plan
is to separate this out into a .net object residing in a web service,
then replace the vb6 class with a different vb6 class which is just a
proxy that calls the web service through a COM wrapper, then back to
the original vb6 class through interop (don't ask). For now,
everything will just pass through. My question is about the design of
the web service.

I had planned to have a new business object class, but the interface
for this class will change shortly after I get this working with the
legacy code. I was thinking of having two interfaces for this class
to implement. One for the legacy code to call, and one for any
new .net user interfaces to call. So now I have three files: two
interfaces and a class that implements them both.

So now I need to expose some sort of interface for the web service.
This is a separate class containing web methods, and this is what the
clients see when visual studio generates the proxy classes.

So how should I hook this together? Instead of two interfaces, should
I create two asmx pages, one for each interface, and have them each
create the business object? Is there an advantage to keeping the two
interfaces in addition to the web service classes and just pass things
through?

tia
brian

[John Saunders [MVP]]

"brianlanni ng" <br**********@g mail.comwrote in message
news:11******** **************@ z24g2000prh.goo glegroups.com.. .

>I have a class that represents a business object. Currently, this
class exists as a vb6 "class" which will be ported to .net.

Is the existing class a COM object? If so (and assuming that high
performance isn't a goal), you could keep it as a COM object and still call
it from the web service. Then, if the VB6 class is large, you could break
off pieces of it to implement in .NET, rather than implementing the whole
thing in .NET right away. The VB6 code could _still_ call the parts that had
been VB6, but which had become .NET.

Eventually, you'd be left with a small VB6 piece that orchestrates calls to
..NET COM objects, and it would be time to remove the VB6 code and just have
..NET call .NET.

In the meantime, you would have made one small change after another, testing
in between, to give you confidence in the port.
--
John Saunders [MVP]