What do I do with an overbloated service class?
Nieve
יש לי סרביס קלאס שמשתמש בלפחות שבעה רפוסיטוריס (מצטער על השימוש
בעברית). לאחר שהתווסף הרפוסיטורי הרביעי התחלתי לחשוב שהגיע הזמן
לרפקטורינג. האופציות הראשונות עליהן חשבתי היו או להוסיף רפוסיטורי אחד
שידאג להעלות את כל האובייקטים שאני צריך מבסיס הנתונים או לחלק את
הסרביס שלי למספר סרביסים. נכון להיום אנו משתמשים בארכיטקטורה המשתמשת
ברפוסיטורי לכל אובייקט כך שאם הדרישות להעלאת, עידכון או מחיקת אובייקט
כזה או אחר ייאלצו להשתנות בעתיד, השינוי יחול רק על מקום אחד-
הריפוסיטורי (היחיד) של אותו האובייקט.
מה דעתכם בנושא?
למרות שקראתי לא מעט חומר על
DDD
אני עדיין רחוק מאד מלהבין כיצד ניתן באמת ליישם את מרבית הרעיונות. האם
רפוסיטורי אחד שידאג להעלות את בסיס האגרגייט שלי יחד עם כל האובייקטים
הנלווים אליו ולעדכן, ליצור ולמחוק רק את הבסיס היא הדרך הנכונה? אם כן
מדוע? האם זה הגיוני לעבוד עם רפוסיטורי לכל אובייקט (בייחוד מאחר
והמשתמש יוכל ליצור, לעדכן, למחוק ולראות את כל האובייקטים באפליקציה
עליה אנו עובדים)?
אשמח לקבל כל עצה שהיא בנושא
גם הפניות לחומר קריאה בנושא יתקבלו בשמחה
Ori Peleg
Gustavo Ringel
Nieve
Many thanks for the prompt reply.
Indeed, we use an IoC that takes care of wiring up the service with
all its repositories. Thing is that my service ctor looks over-
bloated: it takes 7-8 parameters and will contains a similar number of
lines of code inside if not more- I have only recently wrote it, so
that it risks to grow even more since it is one of the main objects of
our domain.
So from what you guys are saying, what is the idea behind the DDD
definition of an Aggregate? How would you implement it with regards to
the example I've given? An aggregate is similar to any other domain
object until you get to the service where it works with the
repositories of its dependants?
On Oct 24, 7:55 pm, Gustavo Ringel <gustavo.rin...@gmail.com> wrote:
> As far as there is high cohesion (all the repositories are needed for a use
> case managed by the service) and considering that the IoC container will do
> the hard work i don't see any problem putting several repositories there...
>
> Gustavo.
>
> 2009/10/24 Ori Peleg <ori...@gmail.com>
>
> > Is it a pain to use even with an IoC container to resolve the dependencies
> > for you?
>
> > 2009/10/24 Nieve <nieveg...@gmail.com>