I have a couple of questions regarding VBScript and ASP Classic:
What is the preferred way to access an MS SQL Server database in VBScript/ASP?
What are best practices in regards to separating model from view from controller?
Any other things I should know about either VBScript or ASP?
If you haven't noticed, I'm new at VBScript coding. I realize numbers 2 & 3 are kind of giant "black hole" questions that are overly general, so don't think that I'm expecting to learn everything there is to know about those two questions from here.
ADO is an excellent way to access a database in VBScript/Classic ASP.
Dim db: Set db = Server.CreateObject("ADODB.Connection")
db.Open "yourconnectionstring -> see connectionstrings.com"
Dim rs: Set rs = db.Execute("SELECT firstName from Employees")
While Not rs.EOF
Response.Write rs("firstName")
rs.MoveNext
Wend
rs.Close
More info here: http://www.technowledgebase.com/2007/06/12/vbscript-how-to-create-an-ado-connection-and-run-a-query/
One caveat is that if you are returning a MEMO field in a recordset, be sure you only select ONE MEMO field at a time, and make sure it is the LAST column in your query. Otherwise you will run into problems.
(Reference: http://lists.evolt.org/archive/Week-of-Mon-20040329/157305.html )
I had to walk away from my PC when I saw the first answer, and am still distressed that it has been approved by so many people. It's an appalling example of the very worst kind of ASP code, the kind that would ensure your site is SQL-injectable and, if you continue using this code across the site, hackable within an inch of its life.
This is NOT the kind of code you should be giving to someone new to ASP coding as they will think it is the professional way of coding in the language!
NEVER reveal a connection string in your code as it contains the username and password to your database. Use a UDL file instead, or at the very least a constant that can be declared elsewhere and used across the site.
There is no longer any good excuse for using inline SQL for any operation in a web environment. Use a stored procedure -- the security benefits cannot be stressed enough. If you really can't do that then look at inline parameters as a second-best option... Inline SQL will leave your site wide open to SQL injection, malware injection and the rest.
Late declaration of variables can lead to sloppy coding. Use "option explicit" and declare variables at the top of the function. This is best practice rather than a real WTF, but it's best to start as you mean to go on.
No hints to the database as to what type of connection this is -- is it for reading only, or will the user be updating records? The connection can be optimised and the database can handle locking very efficiently if effectively told what to expect.
The database connection is not closed after use, and the recordset object isn't fully destroyed.
ASP is still a strong language, despite many folks suggesting moving to .NET -- with good coding practices an ASP site can be written that is easy to maintain, scaleable and fast, but you HAVE to make sure you use every method available to make your code efficient, you HAVE to maintain good coding practices and a little forethought. A good editor will help too, my preference being for PrimalScript which I find more helpful to an ASP coder than any of the latest MS products which seem to be very .NET-centric.
Also, where is a "MEMO" field from? Is this Access nomenclature, or maybe MySQL? I ask as such fields have been called TEXT or NTEXT fields in MS-SQL for a decade.
Remember to program into the language rather than program in it. Just because you're using a limited tool set doesn't mean you have to program like it's 1999.
I agree with JasonS about classes. It's true you can't do things like inheritance but you can easily fake it
Class Dog
Private Parent
Private Sub Class_Initialize()
Set Parent = New Animal
End Sub
Public Function Walk()
Walk = Parent.Walk
End Function
Public Function Bark()
Response.Write("Woof! Woof!")
End Function
End Class
In my projects an ASP page will have the following:
INC-APP-CommonIncludes.asp - This includes stuff like my general libraries (Database Access, file functions, etc) and sets up security and includes any configuration files (like connection strings, directory locations, etc) and common classes (User, Permission, etc) and is included in every page.
Modules/ModuleName/page.vb.asp - Kind of like a code behind page. Includes page specific BO, BLL and DAL classes and sets up the data required for the page/receives submitted form data, etc
Modules/ModuleName/Display/INC-DIS-Page.asp - Displays the data set up in page.vb.asp.
Echoing some ideas and adding a few of my own:
1) Best way to access the database would to abstract that away into a COM component of some sort that you access from VBScript.
2) If you really wanted to you could write the controller in VBScript and then access that in the page. It would resemble a Page Controller pattern and not a Front Controller that you would see in ASP.NET MVC or MonoRail
3) Why are you doing this to yourself? Most of the tooling required to do this kind of work isn't even available anymore.
AXE - Asp Xtreme Evolution is a MVC framework for ASP classic
There are some attempts at making test frameworks for asp:
aspUnit is good, but no longer maintained.
I saw a sample on how to make your own one a few months back.
The example used nUnit to call functions against the website for automatic testing.
I think i got it off here (my line is borked so I can't check)
On number 2, I think you have a few options...
1) You can use COM components developed in VB6 or the like to separate some of your business logic from your UI.
2) You can create classes in VBScript. There is no concept of inheritance and other more advanced features are missing from the implementation, but you can encapsulate logic in classes that helps reduce the spagehtti-ness of your app. Check out this: https://web.archive.org/web/20210505200200/http://www.4guysfromrolla.com/webtech/092399-1.shtml
I agree with #Cirieno, that the selected answer would not be wise to use in production code, for all of the reasons he mentions. That said, if you have just a little experience, this answer is a good starting point as to the basics.
In my ASP experience, I preferred to write my database access layer using VB, compiling down to a DLL and referencing the DLL via VBScript. Tough to debug directly through ASP, but it was a nice way to encapsulate all data access code away from the ASP code.
way way back in the day when VBScript/ASP were still ok
I worked in a utility company with a very mixed DB envrionment, I used to swear by this website: http://www.connectionstrings.com/
#michealpryor got it right
I've been stuck building on ASP, and I feel your pain.
1) The best way to query against SQL Server is with parameterized queries; this will help prevent against SQL injection attacks.
Tutorial (not my blog):
http://www.nomadpete.com/2007/03/23/classic-asp-which-is-still-alive-and-parametised-queries/
2) I haven't seen anything regarding MVC specifically geared towards ASP, but I'm definitely interested because it's something I'm having a tough time wrapping my head around. I generally try to at least contain things which are view-like and things which are controller-like in separate functions. I suppose you could possibly write code in separate files and then use server side includes to join them all back together.
3) You're probably coming from a language which has more functionality built in. At first, some things may appear to be missing, but it's often just a matter of writing a lot more lines of code than you're used to.
Also for database access I have a set of functions - GetSingleRecord, GetRecordset and UpdateDatabase which has similar function to what Michael mentions above
Related
I am new to C#, programming for less than a year. Until now I have been using the Micrsoft SQLHelper class. (copy of text header below) I recently came across Dapper.
Question is, should I switch to using Dapper ?
Although the SQLHelper class has worked with no issues, I don't know how old it is and I don't have enough experience to determine whether I should switch to using Dapper for xyz reasons. Is Dapper the preferred long term solution?
Thanks
// Microsoft Data Access Application Block for .NET // SQLHelper.cs //
// This file contains the implementations of the SqlHelper and
SqlHelperParameterCache // classes.
Is EntLib doing what you need and not inconveniencing you? Then: perhaps stay with it. Dapper would probably be more convenient in a lot of ways, and EntLib is arguably taking a complex API (ADO.NET) and making it more complex (as opposed to Dapper which aims to make things simpler for the caller), but: if the code works... shrug.
If you were starting from scratch, I'd 100% say "don't go near EntLib with a barge pole, Dapper is fine" (disclosure: I'm a little biased), but: if your code is working today, probably best not to touch it unless you have time to fix any problems you get while moving cogs.
So I am looking to freshen up my dev skills. I come from a classic ASP background using VB, so this new .net and Model concept is very foreign to me. I cant seem to get my head wrapped around it yet. I have tried going through the tutorials, but most are C# and I plan to use VB.net.
My needs at the moment are very simple (or at least i thought they were) Does anyone have a simple example or explanation of how I can create a simple page that pulls data from a local SQL Express DB?
I understand how the Controllers and Views work(mostly), but the Models just make zero sense to me
I created a new Model for a very simple database called Test. It has only 5 columns. (Username, Password, Email_Address, Text_number, and UserID (UID). It created a Model1.edmx, but that's it. Nothing else below it. Where the heck do I go from here?
Uggghhh I feel so dumb!! I used to be OK at this, now it's SOOO different!! I miss my T-SQL, Recordsets, and Loops.
If you want db first you should create a new .edmx Model using "generate from database".
When you have created an .edmx model then you usually create your Entity Classes (see tutorials below) with the "add code generation item". You can read about this in one of the linked tutorials, under "Generating Strongly Typed Entity Classes". After that you're ready to go the controller and create your first query to return some data.
I suggest you start watching these free tutorials about MVC3/4, even if they are in C# and you want to use vb.net, I'm sure you can easily understand what's going on since it's clearly explained
http://www.asp.net/mvc/pluralsight
also read these tutorials that show database first approaches
http://msdn.microsoft.com/en-US/data/jj206878
http://msdn.microsoft.com/en-us/data/gg685489.aspx - VB.net project
To connect to your database, you might want to consider an ORM, like one of the following:
Entity Framework
NHibernate
Linq2Sql (built-in/already installed)
Each of these are very popular and make it easy to quickly snap a code-wrapper around your DB. Then, in your model, you use the ORM objects(wrapping your DB) to call through to the DB.
I have quite a deal of experience programing with VB6, VB.NET, C# so on and have used ADO, then SubSonic and now I am learning nHibernate since most of the prospective jobs I can go for use nHibernate.
The thing is, I have been programming based on what I have been taught, read or come to understand as best practice. Recently, someone through a spanner in the works and had me thinking. Up until now, I have been accessing the database(s) from both the core applcation and attached DLLs that I write.
What this persons said ends as follows and hence my question:
I can tell you
that you wouldn't normally want to do this - an external class library shouldn't have access to the database
What I was trying to do was to have a shared/static class for nHibernate sessions that could be consumed in both the global scope of the app and from any dll. This class was to be in a "core" DLL which all dlls and the application reference. Like I said I'm learning nHibernate so it may not be the way.
To say i'm questioning my database access methods is putting it lightly.
Can anyone put me straight on this?
Edit:
I suppose looking at what has been commented already, it depends on how the database is being accessed. I would tend never to put username/password credentials etc hardcoded in any DLLs for any means.
More specifically, my query is in relation to NHibernate's sessions. I have a static class, an helper class, which is called at application start and the new session is then created and attached to the current context, in the case of web applications, and then whenever I need the session I call "GetCurrentSession". This static class is in the "core" dll and can be accessed with any DLL etc that references. This behaviour is intended. My only question is is this ok? Should I be doing it another way?
A couple of reasons would be
Access to the database, how do you cover off username/password
sharing the DLL, a "bad" application may get hold of your DLL and link with it to get access to your database.
Saying this, if you have proper security on files, etc. then I would have thought using a DLL would probably be a reasonable way to go.
Assuming that the username and password are not stored directly in the DLL (but maybe passed as parameters, or passed as a complete connection object) this isn't so bad.
The possible bad practice here might be accessing the same database for the same purpose from different places - core app and DLL. This could get confusing quickly to a new developer, unless the separation is clear and logical.
Myself, I might try to move ALL (or almost all) data access to a DLL just for that purpose, then have the serious application logic (or as much as possible) in the core app or yet another DLL.
We have got many forms(windows app C#) in our application.We have similar steps in most of them - user adds a new object(in a grid),fills values and save.On,save,we validate,and save if everything ok,else show message.Now,adding of object usually means we add a new row with some default values.
Your question is very broad, so I will answer with an equally broad answer:
You should use a pattern such as MVC or MVVM. You probably want to consider throwing in some of the concepts from DDD such as the repository pattern too.
Is this just a data-entry application? Is it really? Reeeaaally??? Are the validation rules very simple and tend to only be things like "is not empty" and "is in range"? Is there not much domain to speak of? Do you not have to integrate with other applications? Are you not really going to interact with any of this data except for reporting purposes?
If the answer to all this is yes then some sort of template pattern might be for you. Base each form on a base class. The base class has a save method. When you save it it can scan the form for all the controls on it, run any of the more obvious validations (less obvious ones can be stored as attributes) and save a database using conventions (or however else you want to do it).
Then again, if it truly is a data-entry application, why even bother to do it in Windows Forms? Slap it together with an Access DB and be done in a tenth of the time.
On the other hand, if you've got an actual domain then your application is not just a bunch of forms is it? The forms are just a way of issuing commands against a domain - and that's the real meat of what you were hired to do. In that case you should go read the big blue book.
So...yeah.
I'm a bit confused here. Microsoft as far as I can tell claims that parametrization is the best way to protect your database from SQL injection attacks. But I find two conflicting sources of information here:
This page says to use the ADO command object. But this page says that the command object isn't safe for scripting. I seem to recall reading somewhere that the command object shouldn't be used in VBScript or JScript because of security vulnerabilities, but I can't seem to find that article.
Am I missing something here, or do those two articles seem to contradict each other?
I could be wrong here, but I think this just means that someone could use the Command object to do bad things. I.e. it's not to be trusted if someone else is scripting it.
See safe for scripting in this article. Every instance that talks about this phrase online, references it as if you are marking an ActiveX control saying "This control does no I/O or only talks back to the server that it came from" but the Command object doesn't do that. It can be used to do a lot of things which could be unsafe.
The "safe" they are talking about and the "safe" to prevent from SQL injection are two different things. The article about using the ADO Command object to parametrize your data is spot on. You should do that.
And, Microsoft further confirms this here:
http://msdn.microsoft.com/en-us/library/ms676585(v=VS.85).aspx
I think "safe for scripting" means "safe to be run from a webpage we just retrieved from some Nigerian prince". The command object should be safe to run on the server.
At work though, back in the day my colleagues didn't trust it so we had an in-house framework that basically did the same thing.