DCSIMG

 Subscribe in a reader

July 2008 - Posts - Guy kolbis

July 2008 - Posts

An application always needs to define objects that can be used through out all the application layers. For example, lets say we are developing a three layers application that includes UI, BLL and DAL, an object/entity sometimes must be recognized both in the DAL and in the UI.

To achieve that we need to define a place that all can reference to and see the entities.

So, when we design the application we need to think about sharing objects between layers.

There are several options on how to do so. I will present two possibilities, however would love to here your thoughts on the matter.

"God DLL"

The way to think about this matter is as a single DLL that all other DLLs are looking at. He knows no one in particular but everyone else knows him. This way there is no circular dependency.

In other wards,  there is one DLL that describes the entire common classes / entities and all the layers in the application must add a reference to it.

"DLL Per Module"

When your application is modularly designed, this concept is better. Lets say that your application enable each customer to see different modules according to license, putting all the common objects / entities in a single DLL is not recommended.

In this case it is better to separate the common types into modules that will be deployed / loaded only if needed.

kolbis כתב בתאריך Thursday, July 24, 2008 1:39 PM
תגים:,

How would you address this issue?

Lets say you have a DAL that uses Linq2Sql and a .dbml file that contains your database ERD (or some tables). The DAL has some CRUD methods that are exposed using a WCF service and you have a client application that adds a reference to that service.

For example, let say that the database contains a table called "Users" and you have a "GetUser" method that should return a user. Now, because we are using a .dbml file we have a table or an entity called User. The client uses the service exposed by the DAL to get a User.

The question resides on what would you pass between the layers?

Basically, we can return the User created by the .dbml file.

Another option is to create an ObjectModel and Map the .dbml User to another User class resides in a Common assembly (for example) and use this class to transfer data between layers.

What would you do?

חברים תודה על התגובות,
לדעתי ישנה בעיה לקבוע חוק כזה מראש של
"אין לעברת"
או
"יש לעברת הכל"
בגדול גם עיברות יכול לגרום לבעיה, הרי כל אחד יכול לתרגם מילה בעיברית לאנגלית בצורה שונה.

עם כל זאת, מאוד קשה לי להתרגל לקרוא לישויות בעיברית אך כחלק מההחלטות, על הצוות להיות מסוגל להתמודד עם מילים "קשות" באנגלית. במיקרה שלי הצוות הוא כ 10 תוכניתנים בצה"ל שאפשר לומר שיש להם עוד דרך לעבור טכנולוגית ולימודית.

בנוסף לא כל מילה ניתן לתרגם לאנגלית שגורה. במיוחד בצה"ל זה קשה.

כמו שכבר הזכרתם, כיצד ניתן לתרגם רב סרן לאנגלית?

לכן בשורה תחתונה אני מאמין שכל מקרה לגופו וישנם מקומות שאין ברירה ויש להשתמש בעיברות, אך עם זאת מתי שניתן להמנע מזה, אני ממליץ זאת בחום.

תודה!

 במשך זמן רב אני מתלבט בנושא ועדיין לא הגעתי למסקנה חד משמעית. לכן אשמח לקבל הצעות ממכם, הקהילה!

אחד האלמנטים החשובים בתהליך האיפיון הוא החלטה על שמות ישויות במערכת. כך למשל החחלטה על ישויות כמו:

User, Soldier, Student וכד'.

לאחרונה התחלתי ביצירת ארכיטקטורה עבור מערכת צבאית ואני מוצא את עצמי מתחבט בשאלה: "לעברת או לא לעברת?"

אז מה זה עיברות?

נניח שיש לנו ישות בשם דרגה.

באנגלית, דרגה תהיה Rank.

בעיברות דרגה תהיה Darga.

כרגע הייתי שמח לקבל ממכם את העצות ועדיין לא לשתף אתכם בדעתי בכדי לא להשפיע על דעתכם.

תודה