Jag tror jag vet vad business object är men jag tänkte bara checka av det. Det har diskuterats en del kring Domain Driven Design vilket jag tycker är intressant. Om jag ska försöka relatera business object till DDD skulle man kunna säga att ett business object är detsamma som tex klassen customer, dvs i business objektet ingår inte customerfactory och customerRepository? Eller har jag missförstått det hela?

Som jag brukar skapa ett business objekt så:

All logik placeras här och anrop till data access objekten.

T.ex. en metod för att skapa en användare, CreateUser(string username, string password, string group).
I presentationslagret så görs en verifiering att användaren har angett parametrar som du kan förvänta dig (@ i en e-post adress).
I business metoden brukar jag alltid göra en check att de nödvändiga parametrarna ej är tomma. Vidare så anropas en metod i DAL (Insert()) som gör nödvändiga databasanrop. Själva poängen här är att du returnerar t.ex. ett UserID från DAL till business metoden som används till att sätta in användaren t.ex. i en grupp.

På så sätt gör du all logik i BLL. Presentationslagret visar endast den information som returneras ifrån BLL och DAL gör alla databasanrop.

Jag hoppas att du förstår hur jag menar.

Om jag förstår dig rätt så menar du att tex customerRepository, customerFactory och customer utgör tillsammans business objektet. Om det är så då förstår jag innebörden i det men är det verkligen så man brukar benämna ett business object? Någon som kan dementera :)

...publicera två inlägg av misstag...sorry...

Jag brukar nog snarare göra det i 4 lager kan man säga

Presentationslager
BBL - Alla logik som jag beskrivit och direkta anrop till DAL

DAL - Är uppdelat i två mindre lager. Ett lager innehåller t.ex. customer objektet med properties för PKCustomer, CustomerName etc. Det innehåller även t.ex. fyra metoder: Insert, Init(PKCustomer), Update och Delete. Init instansierar objektet och fyller properties med data från PKCustomer.
I lagret använder jag även t.ex. SQLHelper eller någon annan databasklass som förenklar för mig (ExecuteDataSet, ExecuteNoQuery).

På det sätt jag använder detta så finns endast DAL objekten i BLL och där görs nödvändiga verifieringar och eventuellt vissa formateringar.

Det är som vi har anpassat metoden till att passa vårat företag, om det är korrekt eller ej törs jag nu inte svara på. Är väldigt intresserad av svar

Det känns inte riktigt som du svarade på min fråga, dvs vad är ett business objekt för något,

I alla fall, där jag jobbar nu så använder vi oss av en 4-skiktad lösning enligt nedan:
- Presentationslagret
- Fasadlagret som ska vara use-case-orienterat
- Affärslogikslagret
- Data access lagret

Föreslår istället en enkel googling:
http://msdn2.microsoft.com/en-us/library/aa581779.aspx#aspnet_tutorial02_businesslogiclayer_cs_topic2

Vad jag menar med logical layer är att, precis som jag beskrev i början, där all logik sker. De beskriver i artikeln följande scenario:

"The Data Access Layer (DAL) created in the first tutorial cleanly separates the data access logic from the presentation logic. However, while the DAL cleanly separates the data access details from the presentation layer, it does not enforce any business rules that may apply. For example, for our application we may want to disallow the CategoryID or SupplierID fields of the Products table to be modified when the Discontinued field is set to 1, or we might want to enforce seniority rules, prohibiting situations in which an employee is managed by someone who was hired after them. Another common scenario is authorization – perhaps only users in a particular role can delete products or can change the UnitPrice value."

Som jag skulle beskriva det så är DAL där du gör själva databasanropen. BLL anropar nödvändiga metoder i DAL baserat på den affärslogik som applikationen kräver.

Jag är osäker på om jag kan beskriva detta mera tydligt än så här. Jag får föreslå att du googlar på 3-tier architecture i annat fall.

Lilly...

Affärslagret har i uppgift att utgöra de operationer du vill utföra.

Låt säga att du har i ditt affärslager Order klass, denna klass har OrderLines
varje Orderline har en artikel som har ett pris. Din OrderLine talar om hur många Artiklar du har av samma artikel dvs st...

Order.OrderLines

OrderLine.Unit
OrderLine.Atricle

Din orderLine kan ha en affärtsmetod som räknar ut priset på din artikel/order line.
OrderLine.TotalPrice <--- Article.Prics * _unit

din Order klass kan ha en metod TotalPrice som i sin tur räknar ut totala priset för alla dina orderLines.

foreach(OrderLine in _orderLines)
{
_total + orderLine.TotalPrice;
}

typ...

sedan har du ex Facrtories o Repositories om du kör DDD i ditt affärslager. Jusrt repositories är den del som ligger närmast ett datalager denna klass har i uppgift att ge dig dina objekt och deras tillstånd.

Order order = OrderRepository.GetOrderByOrderNumber(124545); <--- fyller en order klass åt dig med OrderLines och Articlar...

Factory har i uppgift att i princip skapa mer avancerade entitetsobjekt. sät att Order skall ha massa special inputparametrar som du inte vill skriva vajre gång du instansierar din Order då kan en Orderfactory typ göra det åt dig...

Fjantigt exempel:

Order order = OrderFactory.Create();

class Orderfactory
{
public Order Create()
{
order = new Order(DateTime.Now.Ticks); <--- Order Nummer eller nått...
return ( order );
}
}


Fasaden har sedan i uppgift att som du säger styra usecases.

Orderfasad.Save(order) <--- anropar OrderRepository.Save(order) typ...

Så dina Repositories, Entieter, Factories, Service klasser i Domänlagret (affärslagret)
utgör alltihop din affärslogik typ.

En Service klass kan vara en GasStation.Fill(car,fuel) <--- klass som inte har någon identitet utan mer eller mindre gör saker åt en... i detta fall ger car entiteten en fuel associasion... Oxå affärslogik typ.

Mvh Johan