.NET och DDD
18 views
Skip to first unread message
don Roberto
Jun 15, 2010, 4:52:32 PM6/15/10
to DDD Sverige
Jag slutförde nyligen ett projekt där vi skrev koden i C# och trots
att jag föredrar Java världen så måste
jag erkänna att .NET's partiella klasser gör det riktigt trevligt att
arbeta med "rika" domän objekt. Alltså
domän objekt med beteenden. Det fina är att man kan göra en klass med
beteenden och en annan som innehåller
persistence annoteringar/attribut. Dessa två klasser kompileras sedan
ihop till en och samma klass.
Är det någon annan som gjort några trevliga iakttagelser med .NET och
DDD?
,
// Robert
att jag föredrar Java världen så måste
jag erkänna att .NET's partiella klasser gör det riktigt trevligt att
arbeta med "rika" domän objekt. Alltså
domän objekt med beteenden. Det fina är att man kan göra en klass med
beteenden och en annan som innehåller
persistence annoteringar/attribut. Dessa två klasser kompileras sedan
ihop till en och samma klass.
Är det någon annan som gjort några trevliga iakttagelser med .NET och
DDD?
,
// Robert
Dan Bergh Johnsson
Jun 16, 2010, 2:49:56 AM6/16/10
to dddsv...@googlegroups.com, DDD Sverige
Intressant. Har funderat i sådana banor, men inte haft något bra
tillfälle att prova. Tack för spaningen.
tillfälle att prova. Tack för spaningen.
På liknande sätt har jag funderat på om inte samma mekanism skulle
kunna användas för COP på samma sätt som Qi4j gör i Java. Kanske
inte med riktigt samma brutalt kraftfulla semantiska stöd som just
Qi4j-ramverkrt har, men ändå en framkomlig väg att tillämpa
principerna.
Dan
> --
> Det här meddelandet skickas till dig eftersom du prenumererar på gru
> ppen DDD Sverige i Google Groups.
> Om du vill göra ett inlägg i den här gruppen skickar du e-post till dddsverige@googlegroups.
> com.
> Om du vill sluta prenumerera på den här gruppen skickar du e-post ti
> ll dddsverige+...@googlegroups.com.
> För fler alternativ, besök gruppen på http://groups.google.com/group/dddsverige?hl
> =sv.
>
Joakim Sundén
Jun 16, 2010, 5:33:41 AM6/16/10
to dddsv...@googlegroups.com
Kanske inte exakt detta ämne, men Scott Bellware har skrivit en intressant bloggpost om DDD, .NET och Rails.
Joakim
2010/6/15 don Roberto <robert...@gmail.com>
--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen DDD Sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till dddsv...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till dddsverige+...@googlegroups.com.
Torbjörn Kalin
Jun 16, 2010, 7:04:52 AM6/16/10
to DDD Sverige
En annan funktionalitet i .NET som funkar väldigt bra ihop med DDD är
extension methods.
Dels ges du möjlighet att knyta funktionalitet till ett interface och
därmed dela logik mellan entiteter som delar egenskaper (utan att
använda abstrakta klasser eller statiska funktioner). Dessutom är det
väldigt lätt att skriva deklarativ kod och därmed göra affärslogiken
tydlig och lätt att läsa.
/T
extension methods.
Dels ges du möjlighet att knyta funktionalitet till ett interface och
därmed dela logik mellan entiteter som delar egenskaper (utan att
använda abstrakta klasser eller statiska funktioner). Dessutom är det
väldigt lätt att skriva deklarativ kod och därmed göra affärslogiken
tydlig och lätt att läsa.
/T
Alejandro Coronel
Jun 16, 2010, 7:23:49 AM6/16/10
to DDD Sverige
Det låter intressant, har du något bra länktips till en artikel/
tutorial som visar hur man kan jobba på det sättet med Extension
methods?
Ska jag vara ärlig reagerade jag först mot tanken på att lägga
persistensfunktionalitet i partial-klasser, även om jag är medveten om
att många ramverk bygger på just partial class-tekniken. Känns lite
som att man fuskar med Persistence ignorance-konceptet (å andra sidan
jobbar ju Hibernate med annotations direkt på POJOS...). Finns det
risk att man försvårar ev. framtida införande av t.ex. NHibernate om
man (över)utnyttjar Partial-class-tekniken?
/Alejandro
tutorial som visar hur man kan jobba på det sättet med Extension
methods?
Ska jag vara ärlig reagerade jag först mot tanken på att lägga
persistensfunktionalitet i partial-klasser, även om jag är medveten om
att många ramverk bygger på just partial class-tekniken. Känns lite
som att man fuskar med Persistence ignorance-konceptet (å andra sidan
jobbar ju Hibernate med annotations direkt på POJOS...). Finns det
risk att man försvårar ev. framtida införande av t.ex. NHibernate om
man (över)utnyttjar Partial-class-tekniken?
/Alejandro
Torbjörn Kalin
Jun 17, 2010, 1:54:16 AM6/17/10
to DDD Sverige
Inga länktips...
Men vad gäller deklarativ kod är ju LINQ ett strålande exempel. Och
det finns ju inget som begränsar dig till IEnumerable, utan du kan ju
göra motsvarande för vilken annan klass som helst. I lokala utökningar
kan du skapa redundanta metoder vars enda syfte är att öka läsbarheten
(utan att för den skull skräpa ner det publika gränssnittet).
Gällande hur man knyter funktionalitet till ett interface, här är ett
(nyss påhittat) exempel:
public interface IFileSystemItem
{
string PathAsString { get; }
}
public static class FileSystemOperations
{
public static void Delete(this IFileSystemItem me)
{
// Do something with me.PathAsString
}
}
public class Directory : IFileSystemItem { ... }
public class File : IFileSystemItem { ... }
I det här fallet får File och Directory automatiskt en Delete-metod,
utan att du behöver använda dig av din enda arvsmöjlighet. På samma
sätt kan du låta skilda entiteter som i någon bemärkelse delar på ett
beteende dela på detta beteende även kodmässigt.
/T
Men vad gäller deklarativ kod är ju LINQ ett strålande exempel. Och
det finns ju inget som begränsar dig till IEnumerable, utan du kan ju
göra motsvarande för vilken annan klass som helst. I lokala utökningar
kan du skapa redundanta metoder vars enda syfte är att öka läsbarheten
(utan att för den skull skräpa ner det publika gränssnittet).
Gällande hur man knyter funktionalitet till ett interface, här är ett
(nyss påhittat) exempel:
public interface IFileSystemItem
{
string PathAsString { get; }
}
public static class FileSystemOperations
{
public static void Delete(this IFileSystemItem me)
{
// Do something with me.PathAsString
}
}
public class Directory : IFileSystemItem { ... }
public class File : IFileSystemItem { ... }
I det här fallet får File och Directory automatiskt en Delete-metod,
utan att du behöver använda dig av din enda arvsmöjlighet. På samma
sätt kan du låta skilda entiteter som i någon bemärkelse delar på ett
beteende dela på detta beteende även kodmässigt.
/T
David Rosell
Jun 27, 2010, 6:08:18 AM6/27/10
to dddsv...@googlegroups.com
Lite off topic och lite sent, men här är ett exempel hur man gör samma sak i Scala.
Artikeln ger en konkret beskriving av hur användningen av traits förbättrar JPA (om jag förstått det rätt så är scala's trait samma sak som Extension methods)
http://www.infoq.com/articles/scala_and_spring
Artikeln ger en konkret beskriving av hur användningen av traits förbättrar JPA (om jag förstått det rätt så är scala's trait samma sak som Extension methods)
http://www.infoq.com/articles/scala_and_spring
Reply all
Reply to author
Forward
0 new messages