Ofta när jag tidigare byggt webbapplikationer i ASP så samlade jag ihop alla SQL frågor i en aspfil som jag sen inkluderade på alla sidor som behövdes.
Men nu med ASP.NET försöker jag tänka om lite och istället skapa en klass där jag samlar alla SQL uttryck för varje enskild applikation.
Typ:

using System;

namespace SQLCollection
{
	/// <summary>
	/// A collection of all the SELECT queries
	/// </summary>
	public class SQLSelect
	{
		public SQLSelect()
		{
			//
			// TODO: Add constructor logic here
			//
		}
	}
	
	/// <summary>
	/// A collection of all the UPDATE queries
	/// </summary>
	public class SQLUpdate
	{
		public SQLUpdate()
		{
			//
			// TODO: Add constructor logic here
			//
		}
	}
	
	/// <summary>
	/// A collection of all the INSERT queries
	/// </summary>
	public class SQLInsert
	{
		public SQLInsert()
		{
			//
			// TODO: Add constructor logic here
			//
		}
	}
}

Det blir i alla fall lättare att ändra, byta ut och lägga till frågor än att baka in frågorna i själva koden.
Är det här ett bra sätt eller finns det smidigare sätt?

Har funderat på att samla frågorna i en XML-fil istället eftersom det då är enkelt att ändra uttrycken, även om applikationen körs skarpt (dvs. under det att appliaktionen är under drift). Eftersom frågorna är densamma för alla som kör mot applikationen så kan man ju lägga in dem (XML-filen) i Cachen, vilket borde snabba upp det hela en del.
Är den idén bättre?

Som ni förstår så kör jag (ofta) med 2-skikts lösningar här internt. Vilket har sina nackdelar, men så är det nu i alla fall. Men upplägget är lite desamma med en 3-skikts lösning då jag tex. vill samla ihop namnen på de procedurer etc. som används i applikationen.

Jag är inte systemvetare som ni kanske märker.
Så lite god råd tas tacksamt emot...

Jag skulle faktiskt rekommendera dig att använda lagrade procedurer istället. På så sätt kan du ändra förutsättningen för datat utan att behöva kompilera om koden, samt att de går mycket snabbare att köra då en procedur är förkompilerad.

Med pellesoft som exempel är det över 600 lagrade procedurer som finns att tillgå.

I ditt fall borde det räcka med 2 klasser, en för select och en för (insert, update, delete) och när du kör funktionen skickar du med såväl sp-namn och dess parametrar.

Om du kör SQL server ska du kolla in
Data Access Application Block for .NET

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daab-rm.asp



Annars tycker jag du bör tänka lite mer som nedan.

Du är inne på rätt spår men du har en bit kvar till målet! :)


exempel, överskådligt - ej komplett.. :)


DAL Data Access Layer (detta är en generell klass som du kan återanvända i alla projekt)
MS Data Access Application Block kan användas här.
----------------------------------------------------------------
GetDataset()
GetSqlReader()
ExecuteInsert(a,b,c)
ExecuteUpdate(a,b,c)


MBL Main Business Layer
(Här gör du en klass per objekt som mappar till verkligheten,
typ Produkt, Kund, Leverantor, FilExportUtilClass
----------------------------------------------------------------
Public Class Product
Public Function GetProductList(prodType) As Dataset
Public Function StoreNewProduct() As Integer


GUI layer (codebehind class)
----------------------------------------------------------------
Dim dsProducts As Dataset = P.GetProductList(43)
GuiUtil.DoSomething(dsProducts)


----------------------------------------------------------------
Det här är helt underbart när man ska ändra i system efter 12 månader (och man har glömt det mesta). Eller ta över från någon annan utvecklare.

Jag vill krama alla utvecklare som bygger sina system enligt ovanstående principer :)


ps. om du kör SQL server ska du såklart använda Stored Procedures oxå, och kolla även upp
User Defined Functions! ds.

Håller med Ola, kolla på DAAB.
Microsoft har släppt flera trevliga Application Block, t.ex. för loggning, spara konfigurationer etc.

Man sparar mycket tid genom att slippa bygga dessa delar samt buggar som uppstår när man bygger nytt.

/ Jimmy

Tackar för svaren!
Kör inte med MS SQL Server. Använder Oracle och MS Access.
Har däremot byggt en "DAAB klass" eller en generell DAL klass (whatever?) som bland annat returnerar OleDbDataSet, OleDbDataReader, SqlDataSet och SqlDataReader som jag återanvänder i princip alla projekt. Funkar kanon.

Min tanke är nog mest att jag inte vill låsa upp mig till en viss databastyp. Det bästa kanske är att utveckla för en databastyp (Oracle) och sen göra en migrering till annan databastyp om detta krävs?
Hur bör/brukar man tänka här (som systemvetare)?

Ofta är arbetsgången i mitt fall att utvecklingen sker mot MS Access. Sedan flyttas/migreras databasstrukturen i bästa fall till Oracle (eller varför inte SQL Server). I dessa fall har det fungerat bra med att då endast behöva byta ut SQL syntaxen på vissa frågor så har allt fungerat i den "nya" miljön.
Framförallt gjorde jag i ASP med SQL frågorna samlade i en include fil.
Kanske är det här jag bör tänka om och ändra mitt sätt att utveckla?

Det är ju inte för inte som 3-skikts lösning oftast används...

Björn,

Det är alltid lite klurigt det där med statiska frågor särkilt om man inte kan lägga dem i SPs.
I ditt fall om du måste använda statiska anrop så kan det vara en lösning att lägga in dem så som du säger eller kanske i en assembly resursfil. Blir lite enklare att ändra då.

<code>
string getUserSql = SqlManager.GET_USER_SQL;
</code>

Där du enklet kan ha en property som ovan som går mot en Resurs läsaren och läser in din fråga med samma namn som propertyn.

Fast frågan är om det blir enklare för andra utvecklare att updatera och underhålla ditt system då?
Ibland kan statiska texter i några Data klasser vara en fördel. Då man ser bara _just_ den sql satsen som anges.

Det finns inger direkt KORREKT sätt att göra detta på, det är mer vad du känner fungerar bäst för dig och andra det du känner ger dig störts flexibilitet och kontroll.

Mvh Johan

Jag har en gång i tiden jobbat som du och med precis samma databaser, jag löste det genom att ha en tabell (i databasen) med alla frågor samlade i sedan så hade jag ett globalt objekt som hämtade innehållet i den tabellen vid programuppstart. Sen var det bara att skicka en förfrågan till det objektet när man ville ha en viss fråga och ville man redigera en viss fråga så var det bara att ansluta till databasen och redigera frågan.

Jo, det har jag också funderat på. Idén med XML-filen är ju lite av samma princip.
Läsa in och cacha XML-filen som ett object vid körning (page load). Då blir det även väldigt enkelt att ändra SQL frågorna.

Men efter ovanstående resonemang kommer jag nog att ändra arbetssätt en del. Bla annat kommer jag från start (på spec nivå) bestämma om bättre databasmotor behövs än MS Access. Om så är fallet så utvecklar jag direkt med Oracle som databas redan från start. Sedan har ju både Oracle, SQL Server mfl. bra stöd för migrering till och från varann. Även migrering från MS Access till ex. Oracle funkar ju rätt bra.

Som sagt, det blir nog till att använda båda metoderna...

Tackar för all hjälp och förslag jag fått. Jag läser vidare på "Systemutveckling" forumet. Fanns otroligt mycket bra att läsa där, samt många bra länkar.