Jag tjatar på om objektorientering, nån gång ska det väl fastna:)

Jag har följande klass
<code>
public class Blogs
{

public int BlogID { get; set; }
public Guid UserID { get; set; }
public string UserName { get; set; }
public string BlogName { get; set; }
public string BlogDesc { get; set; }
public DateTime BlogStart { get; set; }

public Blogs(string _blogName, string _blogDesc, string _userName)
{
this.UserName = _userName;
this.BlogName = _blogName;
this.BlogDesc = _blogDesc;
}

public Blogs()
{
//
// TODO: Add constructor logic here
//
}
}
</code>

Var kör jag logiken? Är det i set eller i konstruktorn? Egentligen ska jag väl göra dbanropet i denna klass också? Det ska väl ske från samma ställe som logiken?

Hoppas ni inte tröttnar på detta tjat:(

Om du behöver någon form av logik för t.ex username så lägg det i set.

Db-anrop, t.ex så här:

Blog b = facade.getblogbyid(1);
Blog[] b = facade.getallblogs();

där facade anropar databas.getblogbyid() som anropar en sp eller någon orm-wrapper.

.. men det finns förstås väldigt många olika sätt facade är ju inte helt nödvändigt, OO är överskattat :)

Gör du ett större projekt så föreslår jag att du delar upp det enligt:

Värdeobjekt -> Alla klasser som är håller värden, exempelvis en klass blogg som kanske har variablerna, _bloggID, _anvandarID, _rubrikText, _brodText(oftast rena speglingar ifrån databasklasserna)

Affärslogik -> här gör du all logik

Databaslager -> det är härifrån och endast härifrån du accesar databasen. Detta lagret fyller dina värdeobject ifrån databasen och sedan tar värdeobject som indata och spara ner det till databasen.
Du kan även skriva specailklasser här för att spara data, detta för fall där du saknar värdeobjekt.

Skall du göra något mindra så kan du klämma in allt i en klass, men jag rekomenderar att du bryter ut logik och databasanrop i olika funktioner i alla fall. Det kommer bli mycket enklare och överskådligare.
Och att du ändå fundrar över att ha värdeobjekt som du jobbar mot.
/Fredrik

Om du praktiserar Domain Driven Design så bör din logik ligga i metoder på klassen. Men ev. databasanrop bör ligga i s.k. repositories.

http://en.wikipedia.org/wiki/Domain-driven_design

Jag kan tipsa om en bra metod för att dela in koden i olika lager som kallas "Onion Architeture" som funkar rätt bra:

http://jeffreypalermo.com/blog/the-onion-architecture-part-1/


Lite övriga synpunkter:

Du bör kanske överväga att byta namn från Blogs till Blog(för det verkar vara logik rörande en specifik blog du syftar på) för då blir koden naturligare att läsa:

Ex: IList<Blog> blogs = new List<Blog>();

Om du kör .Net 3.5 så kan du skippa din konstruktor och använda "object initializers" i stället.

Det finns massa olika skolor ang vart logik skall ligga. O avsett design arkitektur så föredrar jag att man separerar DB från entitet. Dvs din Blog lever själv med sina tillstång frikopplat från annan tung logik så som exempelvis Data access... Detta för att få en frikopplad modell för att i framitden om behövs enkelt ändra datakälla, men samtidigt öka en viss återanvändbarhet...

Så jag hade i ditt fall gjort en egen klass som returnerar din bliog med fyllda tillstånd från en annan klass och denna klass skall även vara den som har hand om updatering, radering, sparning av ditt objekt.

Jag föredrar domian driven design som egentligen inte är något spec mer än vad skall man kalla det riktlinjer, idér och guideline för att få en bra OOP design och implementation. I detta fall skulle jag bygge en BlogRepository klass som ger dig den blog entiet du vill ha. Reposiroyn själv ser till så din blog fylls med rätt data. Antingen via ORM ex NHibernate eller LINQ to SQL eller manuell mappning mot exc en SQLDataReader.

Mvh Johan