"Mike" <mr********@NOSPAMATALLcalibrus.com> wrote in message
news:O0**************@tk2msftngp13.phx.gbl...
I have been developing ASP applications for quite a while now. Most of
the apps that I deploy are a typical n-tier setup. ASP GUI on a web server,
Business and Data Components written in VB6 running in COM+ on a separate
server with the SQL database residing on its own server.
Wow, RAD!! Been there and loved every minute of it.
I don't really use COM+ for the transactions but more for the DCOM
capabilities and as a way to control the running program. If I need to
compile out a new version of an component and the website is being used I
can just stop the component and then compile it out. Otherwise VB won't
let me compile it out because the component is in use.
You can register your COM+ app as Server application instead of a Library
application. This way, your app runs in its own DLLHOST.EXE process instead
of running inprocess with inetinfo.exe. It's easier to shutdown the
component in Component Services this way so you can recompile. Also, you
can designate your IIS virtual directory to run High (Isolated) protection.
Your virtual directory will also run in its separate instance of DLLHOST.EXE
that you can find in Component Services. You should avoid running both the
virtual dir and the component in their own DLLHOSTs for performance reasons
(cross-process marshalling, etc). What I used to do is run the virtual dir
in High(Isolated) and run the COM+ app as a Library application. If you
need to replace the dll, simply Unload the virtual directory inside IIS
Manager to release the dll.
My question is how does this translate to ASP.NET. I have read many
articles but have never come across an answer that answers this question
for me. I guess I'm wondering what the best practices are with is comes to
deployment.
Have a look at the Duwamish example on MSDN:
http://msdn.microsoft.com/library/de...duwamish70.asp
It's even better if you can download the whole solution so you can see the
Enterprise template they use. My team and I generally stick to this
methodology, now. Start with a solution, add a Web project, add another
project for the Business Facade, add another project for Business Rules, add
another project for Data Access and maybe other common data objects. Add a
database project to house our stored procedures
Should a lot of the business and data logic I write be contained on the
webserver in the Code Page Behind? Or should I separate it out into like
I am currently doing? If I deploy it like that and need to update
components can I compile over the version out there even if its being used or will I
get an error because the dll its trying to update is in use?
No. Use code-behind to separate presentation code from the aspx page - i.e.
no more "<%%>" tags and "<script runat=server>" tags . Use code-behind also
to handle postback events and to call Business Logic layers through the
Business Facade layer. Example, have the code behind call BusinessFacade to
call DataAccess to request a DataTable, then set a DataGrid's DataSource to
the DataTable and call DataBind(). The important thing is to keep
BusinessFacade the public interface, i.e. code-behind should never directly
call the DataAccess layer.
I know there is a right or wrong answer, I'm just looking for the most
accepted way of doing it as a starting point.
I don't think there is a right or wrong answer. It starts to become an art
after a while, then it becomes a matter of style. Two sets of code may do
identical things but one may look more elegant and perform better than the
other.
