DLL questions. 3

[snowboardr]

1. Is it possible to go direct to the dll and show a page?
like... mydomain.com/mysite.dll

2. Are DLL's faster then a normal ASP function on a ASP page?


3..any other comments would be great.

I have been playing around with dll's the last few days, and you can do some neat things in them, and use them in your ASP app. Now I just want to learn more about dll's in web apps. There isn't really much info about them on the web, I have looked.

-J

 

[link9]

The term to search for is COM

When you write a vb project and compile it as a .dll, it is referred to as a COM object. You should have no problem finding a wealth of information out there on the subject.

As to your question, yes, a dll is much faster and that's because it's compiled code that is executing, as opposed to the interpreted nature of ASP classic (ASP.NET is actually compiled). Now whether or not you want to put ALL of your logic into a COM object... it's up for debate. Consider this:

The whole idea of COM development is to break up programs and componentize (??) them into little pieces that can be put together to form an application. The smaller and more specialized the piece, the easier it is to work it into other applications... hence, the idea of re-useable code, a big part of object oriented development.

Now, if you go and put everything into one big component, then you have pretty much relegated that component to one specific task, and the chances of you ever being able to re-use it in some other application are pretty low. Does this make sense? Sometimes, yes, it does. For instance, if I were going to write a piece of distributable ASP code (for sale, perhaps), then I might want to encapsulate the bulk of my logic into a component and distribute is as such. The source code is protected at that point. You expose methods and properties to do your work by, but the user will never know exactly how you implemented anything... only how to use it (another property big in OO, which is referred to as abstraction).

WROX writes some great books on this subject, and I would highly recommend reading them. But further than that, I would recommend jumping on the .NET bandwagon, and checking out the features available in the next generation of ASP. You'll thank yourself.

Hope that helps.
paul

 

[RushiShroff]

Courtesy : msdn.microsoft.com/workshop
No it is not possible to go to mydomain.com/mysite.dll

Well if you want to test in microseconds there is one company asp2dll.com which gives demo also online.It measures time in micro secs and shows you haw fast dlls are.


I showed you two examples of using MTS components written with Visual Basic in an ASP-based application. In both cases, Visual Basic was used to write the data access layer and ASP was used to define the presentation layer. That is an important characteristic of a three-tier system. The presentation logic never mingles with the data access code. What changed between the first and second examples is where the business logic was defined—
what it means to submit a sales order. In the first example, this business logic was defined in the CBroker class of the Visual Basic-based DLL. In the second example it was defined in ASP code. Both examples used the MTS runtime environment to guarantee the ACID requirements of their transactions. The ASP code for these examples can be seen in SubmitOrder1.asp and SubmitOrder2.asp in the source code.
</msj/images/dingbats/indent.gif> The fact that IIS/MTS integration allows you to create transactional ASP pages doesn't mean that you have to use them. You might elect to maintain your business logic in a DLL as opposed to ASP code. There are a few reasons you might do this. Using classes available in Visual Basic or C++ will make it easier to maintain and extend your business logic with much better type checking and debugging capabilities. Compiled DLLs give you much better versioning control. Furthermore, you can use these DLLs from standard COM client applications as well as ASP clients.
</msj/images/dingbats/indent.gif> You might choose to maintain your business logic in ASP because of the advantages of a compile-free development environment. You might find it easier to make revisions without having to rebuild and replace a DLL. Now that you've seen the issues you'll need to consider, you're ready to make that choice.

he main benefits of COM are that Business logic can be shared between multiple applications, scalability, security and reliability. Just because you move functionality to a COM component means that it will run faster. If the process you have written in VBScript is very large then there is a good chance it will be faster in COM. If it's relatively small code, then it's more likely that it won't be faster. There are a lot of variables that determine execution/response time. One thing to think about, if your COM server is separate from your IIS server then every call from the IIS server requires and RPC call across your network. The more RPC calls you perform, the more likely the repsonse time will be slower.

There are many very good reasons for using COM components other than speed. A properly designed COM layer can make your application easier to build, modify and maintain - for a pro developer, that's often worth a LOT more than performance.

One component can produce a single page displaying simple HTML text, or it can display computed data originating from database tables specifically designed for individual users or groups. An entire interactive site, with multiple related pages, can be contained in one component. Shopping cart systems, a series of reusable input forms with built in data validation, office related information management sites, and many other application can be encapsulated and saved within a single DLL file. The class libraries you build can be saved and reused in other components. As an added bonus, distributing compiling source code in the form of a DLL component will keep your code manageable and protected.


Here's a place to start if you are interested in seeing some code with explainations.

http://visualbasic.tqn.com/cs/comdcom/

If the query you run is long and complicated, you could think of deploying it as a stored procedure or a view in your database server.
For instance i use a view when i just have to display static info,sometimes from as many as 12 tables. these views could be called from your vb dll's. the advantage in using a view is u can dynamically add WHERE clauses from ur vb dll and then excute the view!
For inserts and updates a stored procedure would be the choice. Again u can call stored proc's using the ADO command object from your dll's Rushi Shroff Rushi@emqube.com
&quot;Life is beautiful.&quot;

 

[link9]

If you compile your dll as an exe, and give the directory it's located in executable permissions, then you can:

http://mysite.com/myEXE.exe?some=stuffhere

But that's an out of process component, and so every time it's called, it spawns a new instance, and can therefore bog down your server, if you have enough traffic.

A dll will run in the same process as ASP, therefore not creating another process, and increasing performance.

Personally, I'd go the .dll route, unless you have a very good reason to the contrary. Our online survey software uses and out of process component, and on high traffic days, our server is not a happy camper.

 

[snowboardr]

Thanks for your responses. Rushi, I know that you can go direct to a dll such as mydomain.com/mysite.dll I have seen it done many times. And I am very close to doing it myself. Thanks link9 for pointing out about problems with an exe, slowing down the server probably wouldn't be the best idea that was my main reason to go with a dll. More power, faster processing etc. I'll see how it goes I guess.

- Jason

 

[Ovatvvon]

Link9,
is there a specific book by Srox on this subject you have read and/or would recommend? This is the next area of study for me before getting into .NET

Thanks in advance! -Ovatvvon :-Q

 

[BBirkett]

Link9,

Searching for COM in some browsers finds almost anything!!! If the search engine includes urls in their search then it can find anyurl.com, tek-tips.com etc!!

Was just using google.com and was looking for some COM materials, and worked this out for myself!! Thought i'd let you guys know Brett Birkett B.Comp
Systems Analyst

 

[Ovatvvon]

BBirkett,
google is a web spider searcher, it scans all web pages for text matching what you typed, includeing URL's. Try

http://msdn.microsoft.com/library

and search for &quot;com&quot;. -Ovatvvon :-Q

 

[link9]

Ovatvvon,

I read &quot;Beginning COM development with ASP&quot;, and thought it was a very good read.

However, it covers material mostly with VB6, and I don't know if you read my post about .NET, but if I were you, I'd jump on that bandwagon yesterday. I'm sure that WROX has something out with .NET treatment and COM now. I'd suggest that route.


paul

 

[Ovatvvon]

I was going to hold on another month or so and make sure I know xml good and well, and was going to make sure I understood com as well...figured it would still be helpful to know older stuff and would help set me up with understanding the .net stuff. Is this bad thinking? You think I should just finish the xml stuff and then get right on the .net stuff?

Are you following the croud that seams to want C#.NET or are you thinking VBscript.NET for the new technologies? What are you thoughts on that subject?

(Got 9 months until I'm a free man again and will decend into the Atlanta area where there seams to be a lot of competition. So the faster I learn the more important stuff, the better.) -Ovatvvon :-Q

 

[link9]

Well, here are my thoughts on the issue.

As far as C#... I'm just undecided. I read MSDN mag, and nearly everything they put in there for ASP.NET is in C#. So that makes me want to go that route. My first language was C++, but I didn't get very deep into it, and learned OO principles in an academic language called Eifel. Got a little bit of JAVA treatment right before graduation, and then it's all been VB and VBScript since then. I was horrified at first, as VB has always been a crippled language, but that's what I had to use, so I adapted.

Now that I've been using it, I have grown to like it, and now, with .NET, VB is a full fledged object oriented language (about as close as anything else out there). One of the main principles of .NET is to have software judged by the design, rather than the syntax. Now there's an idea. And I have to say I'm quite impressed so far in the little bit of dabbing I've been doing in the technology.

It seems just as powerful as C# or C++, and so I'm sort of leaning towards VB, just because all of my practical &quot;real world&quot; experience has been in this language. I'm very comfortable with the syntax, and am flat out tickled with the new features.

Again, though, I'm not 100% either way. I'm going to a conference next month and I'm going to lick my finger and stick it in the wind with the developers down there to get a feel for what others are going to do. Since that's how things are really decided, anyway.

The few user-groups I've attended seem to be split about 50/50 so far.

Boy, that was a long winded way to say &quot;I dunno&quot;, wasn't it?

So on to the other question of what I think you should do. Eh... as you know, I'm no seasoned veteran of IT (or at least I think you know that, or you do now), and I would not claim to have all the answers.

That being said, I honestly would go the .NET route, since .NET treats COM deployment differently that ASP classic does. Gone are the days of compiling a .dll, and registering it everywhere you want to use it. You now add your class to the plethera of other classes that are installed with the framework, and simply inherit them into your pages, just like you would any other object. Very very cool, and much much better. It's more seamless now.

Additionally, debugging a classic COM object was a bit of a hassle. The best way I could ever figure out to do it was to start the project in a standard .exe, abstracting all the future functionality of the object into a single class, and then writing a little form to simulate input, and return output... and of course, the module to simulate the ASP code that would instantiate and manipulate the object at run-time.

Bye-bye.

Now, as long as you know where the source code is, and can tell your brand new wicked-cool .NET IDE where it is (EVEN IF IT'S ON A REMOTE MACHINE!), then you start your debugging in your aspx file, and when you invoke a method of your object, the IDE steps right over into your VB (or C# or whatever) source code for the COMPILED object, and you are well on your way to debugging in record time.

Oh, and did I mention you can debug SQL Server SPROCS in the same manner?

Think about that... those are compiled binary objects out there, and the thing is smart enough to go grab the source code, and step through it. Heck, ASP is now compiled, too, for that matter.

Oh, man... I could just go on and on and on and on about how sweet this new stuff is. I guess I already have, eh?

So, yea, I really think you ought not to monkey with the old stuff, and just move on. There are enough differences that IMHO, you'd be wasting your time learning the old stuff.

So... Atlanta, eh? Just don't try to get my next big job, OK. ;-)

be good,
paul

 

[Ovatvvon]

LOL,
Paul, you always explain things in just the right way. It's no wonder why you've been the leading 'hancho' here since I've been here at least...perhaps longer?

Your insight was very helpful. I hope to hear any updated info you have to offer after the .net conference. I'm unable to attend it unfortunately...but anything you can fill me on (or I'm sure others would love to hear about it as well), I'd greatly appreciate it!!

Heh, you're near Atlanta? I knew you were in GA, didn't know Atlanta though...I was just down there this last weekend for Easter visiting the In-Laws. Chances are, I'd probably not even be able to 'find' your next big job even if I knew what the company's name was...more or less humor there, but Atlanta is so huge...like trying to find a needle in a hay stack. ;-)

Thanks again! -Ovatvvon :-Q