Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / November 2005

Tip: Looking for answers? Try searching our database.

Bloated webservice

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
PKSpence - 28 Oct 2005 20:23 GMT
I'm currently involved with a classic ASP project that consumes an in-house
developed webservice written in VB.NET. The webservice is approaching 50K
lines of code with no end in site. Presently, it takes about 30-seconds for
the webservice to load before an interface is displayed. Some of the methods
are specific for a particular module of the app and aren't used anywhere
else w/in the app. My question is... would be a better practice to break up
some of the w/s code into different classes, then load those classes as
they're needed. Currently *all* the code is in one class. What are the
advantages and disadvantages of taking this approach? We're about to
starting two new modules to the webapp and now would be the time to start
employing this methodology if it's advantageous to do so.

Thanks!
PKSpence - 02 Nov 2005 20:49 GMT
No response?

> I'm currently involved with a classic ASP project that consumes an
> in-house developed webservice written in VB.NET. The webservice is
[quoted text clipped - 10 lines]
>
> Thanks!
Henrik Gøttig - 03 Nov 2005 12:30 GMT
> No response?

Hi

I will give one :-)

One disadvantage I could think (if I have to find one) is that your
client (classic ASP webapp) have to look up two services. Hmm.. no big
deal, but like I said: If I have to find a disadvantage.

Generally it is (at least I think so) considered a good approach to
design your webservices coarsegrained. But the one you seem to be
developing seems VERY coarsegrainged.

Try to model the services around the business domains that your services
access, eg. accounting, inventory, sales, etc, and create a service for
each domain.
You will find yourself in "in-your-head-discussions" of where to put (in
which service) some of the webmethods, but that is only naturally :-)
And most important of all. It is the foundation of separation of concerns.

Hope that helps.

Regards
Henrik
PKSpence - 03 Nov 2005 15:19 GMT
Thanks for your input! It sounds like you're suggesting to separate the
business domains into different webservices, not classes w/in the same
webservice. Correct?

>> No response?
>>
[quoted text clipped - 21 lines]
> Regards
> Henrik
Henrik Gøttig - 07 Nov 2005 07:52 GMT
> Thanks for your input! It sounds like you're suggesting to separate the
> business domains into different webservices, not classes w/in the same
> webservice. Correct?

Yes, that is exactly what I am suggesting.

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.