Namge classer

.NET

10 svar · 624 visningar · startad av icaaq 25 aug. 2004

icaaqMedlem sedan okt. 20005 273 inlägg

Frågan25 aug. 2004 11:37#1

Tjenare.
Jag har följande lager i min lösning.
- Datalager
-mySQL

- Data accesslager (DAL)
- Som pratar med databsen

- BusinessLogik : ärver DAL
- Här skapar jag mina objekt som fylls med data från mySQL

- Presentationslogik
- Code-behind i aspx-filerna

- Presentationslager
- aspx-filerna

Nu undrar jag hur ni namnger era objekt som skapas i BL då de oftast ser ut som följer för min del.

[red]
using System;
using System.Configuration;
using System.Collections;
using System.Data.Odbc;
using Spira.DataAccess;

namespace Spira.User
{
	#region Public Events
	public class UserInfo : Spira.DataAccess.OdbcData
	{
		public UserInfo(): base(ConfigurationSettings.AppSettings["ConnectionString"])
		{}
		
		public User fetchId(string UserName, string Password)
		{
			User user = new User();
			string SqlStatement="SELECT pk_Userid, fldUsername, fldPassword, fldFirstname, fldLastname FROM tblUser WHERE fldUsername='"+SqlSafe(UserName)+"' AND fldPassword ='"+SqlSafe(Password)+"'";
			System.Data.Odbc.OdbcDataReader dr = RetriveDataReader(SqlStatement);
			while(dr.Read())
			{
				user.Id = Convert.ToInt16(dr["pk_Userid"]);
				user.Firstname = Convert.ToString(dr["fldFirstname"]);
				user.Lastname = Convert.ToString(dr["fldLastname"]);
			}
			return user;
		}		
	}
	#endregion
	#region Private Events
	public class User
	{
		private int _id;
		private string _username;
		private string _password;
		private string _firstname;
		private string _lastname;
		public int Id
		{
			get
			{
				return _id;
			}
			set
			{
				_id = value;
			}
		}
[/red]

Det innehåller ju en class där alla databasanrop görs (userInfo). insert, update, delete och selects med olika kriterier. Sen en class där jag skapar objektet (User) som jag oftast skickar till PL antingen som ett objekt eller i en arraylist med flera User-objekt.

Har ni några allmänna tips om hur man ska namnge sina objekt/classer??

mv icaaq

PaceMedlem sedan juni 20019 024 inlägg

25 aug. 2004 11:58#2

Jag gör enligt följande. Låt säga att vi har en applikation som heter webForum för enkelhetens skull.

Vi kan då ta forumlistan som exempel i affärslogiken:

webForum.Forum - innehåller vanliga objekt för att hämta en lista över alla forum, lägga till, ta bort och uppdatera forum
webForum.ForumEntry - en "item" som innehåller ett enstaka forums värden, vanligtvis en jävla massa properties.
webForum.ForumCollection - eventuellt gör jag en egen collection med lite upphetsande specialfunktioner, annars nöjer jag mig med en ArrayList.

Presentationslagret lägger jag enligt följande:

webForum.UI.Forum - här har vi forumlistan. jämför med http://www.webforum.nu/forumdisplay.php?forumid=191
webForum.UI.AnnanSida - övriga sidor får en egen class under UI

Kort och gott:

- All presentationslogik ligger i ett undernamespace som heter UI (User Interface).
- All affärslogik ligger allt som oftast direkt i rooten av namespacet (webForum).
- All datalogik ligger i webForum.Data.

Jag avskyr namn som "webForum.DataAccessLayer" och "webForum.BusinessLayer".

icaaqMedlem sedan okt. 20005 273 inlägg

25 aug. 2004 15:09#3

Det låter som en bra idé. Ska suga på den lite över natten.

Övriga förslag??

mv icaaq

GladhMedlem sedan maj 20012 812 inlägg

25 aug. 2004 18:13#4

icaaq, har du funderat på en ORMapper. Det ser ut som att du skriver onödigt mycket kod för varje klass.

Om du istället för att ha en UserInfo, VisitorInfo, ItemInfo osv osv har en gemensam klass som kan ta vilket objekt som helst och fylla det med data från databasen så kommer du spara riktigt mycket tid när du programmerarer.

Sedan gillar jag inte iden att BizLibet ärver från DAL:et. Ditt dal skall vara helt fristående från ditt BizLib. Däremot så skall BizLibet känna till ett Interface mot Dalet, som du har det nu så har du kopplat ihop ditt DAL med ditt BizLib lite väl hårt, IMHO.

Så här bygger jag mina applikationer med flera lager.

- UI (Typ webapplikation eller winforms eller något annat) vet allt om BizLibet och kan få tag i alla dess klasser som finns där. Men är endast kopplade genom en reference.

- BizLibet, det är alla mina klasser som kommer att användas av applikationen, typ User, Order, osv osv. BizLibet vet inget om DAL:et men har en reference till ORMappern's Interface

- ORMappern, här fyller jag mina objekt och collections med data från DAL:et. ORMappern består i princip av 3 funktioner (det finns några till) och det är LoadData(), SaveData(), DeleteData(). ORMappern bryr sig inte heller om vart jag spara min data, om det är i en XML-fil eller en Access databas eller en SQL Server, den känner dock till Interfacet för DAL:et

- DAL:et. Dalet har förmågan att använda sig av så många olika datakäller som jag orkar hantera. Varje ny datakälla (Access, MySQL, XML-fil) implementerar ett Interface IDataSource som ORMappern använder sig av för att hämta data och för att spara data. Just nu har jag bara en klass och det är för SQLServer, men om jag behöver ändra min datasource till en MySQL databas så kan jag enkelt gör det utan att behöva ändra i några andra lager.

Det du måste göra om du byter ut din MySQL mot en SQL Server, är att du skall gå igenom alla din Info klasser och ändra så de ärver från System.Data.SqlClient istället, samt att du måste kontrollera alla SQL statements så att de fungerar mot en SQL Server. Jag skriver en ny klass som kan hantera kommunikationen med MySQL och så fungerar min applikation som tidigare.

Så löst kopplat är bra, vill man koppla det ännu lösare så delar man upp sin applikation i flera skikt och lägger varje skikt på en egen dator och låter dessa kommunicera med varandra via WebServices eller .NET Remoting, det är dock lite överkurs.

Själv namngivningen av klasserna är inte så intressant, men jag brukar ha följande.

[FöretagetsNamn].[ApplikationensNamn].[LagretsNamn].[ClassensNamn]

Så om jag jobbade på MS och gjorde Word och skrev en Fil klass i bizlibet så blir det:

MS.Word.BizLib.Fil

Sedan om det är flera skikt så hamlar det mellan ApplikationensNamn och LagretsNamn, eller så byter jag ut LagretsNamn mot skiktnamnet: FrontEnd, MiddleWare, BackEnd

- Magnus

icaaqMedlem sedan okt. 20005 273 inlägg

25 aug. 2004 19:36#5

Fan ........måste läsa massor känns det som.....

JAg ska kolla lite trådar om ORMapper....

mv icaaq

renholmMedlem sedan apr. 20012 266 inlägg

25 aug. 2004 20:51#6

Har själv relativt nyligen börjat utveckla en O/R Mapper i samband med stöd för fler databassystem än MS SQL Server. Då det inte heller finns någon prestandard fördel med att använda Stored Procedures är en O/R Mapper det självklara valet. Finns en del intressant läsning om det, själva tekniken är inte så svår utan det gäller att strukturera den på ett sådant sätt att du kan göra alla dina dataoperationer med den.

GladhMedlem sedan maj 20012 812 inlägg

26 aug. 2004 05:25#7

Då det inte heller finns någon prestandard fördel med att använda Stored Procedures är en O/R Mapper det självklara valet

Både rätt och fel, det finns alltid en prestandafördel vid användadet av en SP om ändå det endast är första gången som SP körs, det andra är att man mycket väl kan använda en SP istället för dynamisk SQL i din ORMapper.

I och med SQL Server 2000 så sparas även execationsplanen för dynamisk SQL om man skriver ut den fulla sökvägen till tabellen. Alltså det räcker inte bara med [dbo].[Customer] utan man måste skriva ut hela sökvägen med servernsnamn först också, annars så sparas inte planen och prestandan blir sämre än med en SP.

Sedan finns det andra fördelar med SP, man kan enkelt läggt till logik i SP som blir mer komplicerat att lösa med dynmasik SQL, speciellt om det skall genereras från en ORMapper.

- Magnus

icaaqMedlem sedan okt. 20005 273 inlägg

26 aug. 2004 06:43#8

Har ni skrivit era egna ORMappers eller använder ni någon färdig?

mv icaaq

GladhMedlem sedan maj 20012 812 inlägg

26 aug. 2004 09:10#9

Jag har skrivit min egen, och det gjorde jag för att lära mig mer, men är du inte intresserad av det, utan bara vill komma igång med ditt eget projekt så använda någon färdig.

Det tar ett tag att skriva en ORMapper även om det bara är grunden, sedan kan man bygga ut den efterhand.

- Magnus

renholmMedlem sedan apr. 20012 266 inlägg

26 aug. 2004 13:27#10

Gladh skrev:

Då det inte heller finns någon prestandard fördel med att använda Stored Procedures är en O/R Mapper det självklara valet

Både rätt och fel, det finns alltid en prestandafördel vid användadet av en SP om ändå det endast är första gången som SP körs, det andra är att man mycket väl kan använda en SP istället för dynamisk SQL i din ORMapper.

Dock uppstår det problem om du ska ha stöd för fler databasmotorer och behöver då skriva dubbelkod för både SP och dynamisk SQL.

Om jag med dynamisk SQL använder "yoda.dbo.Tabell" kommer planen sparas? (yoda = servernamn)

GladhMedlem sedan maj 20012 812 inlägg

26 aug. 2004 17:55#11

Dock uppstår det problem om du ska ha stöd för fler databasmotorer och behöver då skriva dubbelkod för både SP och dynamisk SQL.

Det är väldigt enkelt att lägga till stöd för en SP. Du har redan kod som skapar Parameters, för jag antar att din SQL är parametriserad.... Så det enda du behöver är i din MapperFil/Ett attribute där du skriver namnet på SP, och din ORMapper kollar sedan om du har ett värde där och så fall så skapas ingen dynamsik SQL utan man använder SP's namn istället, skulle kunna tänka mig att det MAX behövs 10 rader kod, för att lägga till stöd för att använda SP's i en ORMapper som redan har Parametriserad Inline SQL.

Som jag förstått det så skriver man ServerName.Databas.Databasägare.Tabellen och då skall exekveringsplanen sparas så man inte måste skapa om den varje gång, det betyder att du inte tappar så mycket prestanda jämfört med en SP, fördelen med en SP är dock att du kan trima din SQL kod så den blir så snabb och specifik som möjligt, medans din dynamisk SQL från ORMappern måste vara hyfsad generell eftersom den skall stämma till alla objekt.

Min ORMapper kallar på en DataAccessFactory, som skickar tillbaka rätt DAL för mitt DataStorage. Dessa olika klasser implementerar alla IDataSource interfacet och det gör att jag enkelt kan skriva en ny klass för ett nytt datastorage och bara låta det stödja mitt interface IDataSource och vips så kan jag använda det.

- Magnus