Richard Bell
6/28/2004 8:16:00 PM
Thanks for responding Sunny. I do also appreciate your comments. I believe
that this is an important issue and I do want to understand all points of
view. I can''t really inline again but regarding my reasons
#1 It''s more than one line. You need to define more classes and you need the
code to obtain the address of the remote server etc.
#2 Regarding size, the binaries for most configurations that I have checked
is on the order of 60% larger. In byte terms the numbers are small, but a
small number multiplied by a big number is still going to be a big number.
#3 I am refering to the bespoke method required to obtain the address of the
server, unless it is hard coded.
#4 It may break the code because of #3.
#6 I am not aware of how, at least without additional coding, or a v2
interface, you will force your strongly named ''general'' assembly to bind
with a specific server. Unless I am missing something, I believe that you
will always load the newest server on the same end point using the
interface/abstract class method.
Regarding the cons
#1 On this forum
#2 But you have a separate assembly with the interface/abstract class method
in any case.
#3 Dataset is marked as serializable, but I suspect that the intention is to
pass by value. It is after all a disconnected data set.
#4 My point here is that a bug in itself does not invalidate the approach.
It would justify workarounds.
#5 I do not believe that using interfaces to control versioning is good
practice.
#6 Difficulties in scripting config files does not invalidate the
methodology. Location transparency is an important design goal.
#7 I suspect that this will correct itself over time.
Anyway, thanks again.
"Sunny" <sunnyask@icebergwireless.com> wrote in message
news:ub8aSaUXEHA.1164@tk2msftngp13.phx.gbl...
> Hi Richard,
>
> it seems that it is exactly a matter of choice. You like it, you do it.
>
> I''ll inline only a few comments.
>
> In article <#G$3v2SXEHA.3988@tk2msftngp13.phx.gbl>, richardb@rogge.co.uk
> says...
> > This seems to be a touchy issue, but I think that it is important one
and I
> > would like to promote an objective discussion with those who are
interested.
> > The reasons why I believe that you should use client side proxies and
> > instantiate remote objects using the new operator wherever possible are
as
> > follows:-
> >
> > #1 Less code is required and it''s simpler.
>
> Less? One line more is significant?
>
> > #2 The overall footprint is smaller.
>
> How? You still has a separate assembly.
>
> > #3 You do not need to code, maintain, document and support bespoke
> > configuration methods.
>
> Which methods?
>
>
> > #4 Changes to the remoting framework will not break your code and may
> > improve it.
>
> How does it breaks interface or base class approach? And how overall
> improvement in the remoting infrastructure does not affect interfaces
> based solution?
>
> > #5 Supports location transparency, including in-process activation out
of
> > the box (to the extent that it is possible) which has been a design goal
of
> > every remoting framework that I have ever come across, including COM and
Net
> > remoting.
> > #6 Tightly integrates with .Net versioning out of the box which I again
> > believe is a design goal of remoting in .Net. In fact to quote the
MSDN -
> > "Remoting was designed to work with strong-named assemblies."
>
> And again, what''s the difference. I have strong-named interface
> assemblies as well.
>
> >
> > The latter point may become crucially important as we move back towards
> > ''smart clients''. Side-by-side running will be critical to the avoidance
of a
> > distributed version of the so called ''dll hell''. Client side proxies
allow
> > granular control over which clients bind to which servers, even over the
> > same end point. Of course, in a perfect world, we would not have to
> > anticipate any versioning issues. A v1 client accessing an interface
from a
> > v2 server should get the same service. But we do not live in a perfect
world
> > and there may be other reasons why you might not want a v1 client
accessing
> > a v2 server. Perhaps the v1 client has not yet paid for a v2 service.
>
> Yes, I do agree. But still if I want to allow older clients to run with
> the newer server, interface/base abstract class is less restrictive. I
> can brake the old clients if I want to, or I can work with them as well.
>
> >
> > I have seen a lot of reasons put forward for not using new to create
client
> > side proxies from various sources. However, it is not clear to me that
they
> > have been entirely convincing.
> >
> > #1 You need to distribute implementation assemblies:- This is simply not
> > true.
>
> Can you tell where have you read that reason?
>
> > #2 Soapsuds strips implementation from serializable objects:- But you
can
> > put them in a separate assembly.
>
> Yes, and ... one more assembly to distribute.
>
> > #3 You cannot remote typed data sets:- I have not tried, but why would
you
> > want to? Wouldn''t the performance hit be onerous?
>
> Because that is (by adds :) ) one of the corner stones of .net, easy
> data access :). I do not use them as well, so I have no opinion, but if
> MS publish everywhere that DataSets (typed ones) are the way to go, and
> you already has a solution based on that, it''ll be better to use them.
>
> > #4 Various bugs with soapsuds:- I have not been able to replicate the
ones
> > that I am aware of. Maybe they have been fixed. Perhaps there are
others.
>
> It seems that "they" are not fixed, at least I can not find a newer
> version.
>
> > However, if every piece of software which had a bug was abandoned, we
would
> > not be programming on a Windows platform right now.
>
> How said that remoting and partners are only for Windows? I have some
> server implementations (just playing for now), which run under
> Mono/Linux. With interfaces, I have just to recompile.
>
>
> > #5 Interfaces promote good design:- True, but then again, you are not
> > precluded from using interfaces alongside client side proxies.
>
> True. I just don''t see why to do both of them.
>
> > #6 Location transparency is dangerous:- Well, as I have already
mentioned it
> > is a design goal of every remote method invocation technology that I
have
> > ever come across, including, I believe, .Net.
>
> Only in this newsgroup you can find a lot of examples (problem reports)
> for not-working solutions, based on bad config files, which leads to a
> local copy of the object using "new". And what an effort is to track
> down such a problem and fix it. If it was abstract class/interface, you
> will always know if something is wrong.
>
> > #7 It''s cumbersome to code:- Maybe, but a minute or two adding a build
event
> > to the server assembly project does the trick. No doubt future versions
of
> > the IDE will hook things up to generate the proxy code for you the way
ATL
> > did.
>
> Still, you have to use VS.Net and external tool. As I said already,
> there are other platforms, IDE''s, compilers, etc.
> Also, if you have tried to work with delay signed assemblies in a
> solution with 5-10+... projects, and have hit the limitations VS.Net
> has about using an external tools and dealing with the events, you will
> know that using external tools as part of a VS.Net solution is indeed
> cumbersome. You may refer some threads I have started in vsnet.ide
> newsgroup. And yes, this is only my preference not to use external tools
> as much as I can avoid them.
>
> >
> > So there we are. I realise that I am risking my neck and the associated
> > wrath of some posters here, but I am genuinely interested in trying to
get
> > to the bottom of this issue. Of course I am not saying that there will
not
> > be circumstances under which using a client side proxy does not make
sense.
> > But I believe that the use of the new operator on a client side proxy
should
> > be the architecturally preferred scenario. I would be very happy if an
> > objective argument could be constructed to the contrary.
> >
>
> As I said - you like it, you do it. This starts to be a religious
> discussion. For me the interface/abstract class way is better. I have
> never argued that the other way is bad. If you revise all my post where
> I do advice the interface approach, there are always words like "in my
> opinion", or "I will advice". I''m not an expert though. I do not want to
> say "interfaces should be architecturally preferred scenario".
>
> Cheers
> Sunny
>
> P.S. I really do appreciate your opinion. Different points of view are
> what makes the progress.