Jaz Chana wrote:
Thats easy to translate into a DAO pattern;
{code}
class SandwichDTO {
String name;
float sandwichPrice;
List<Ingredients> list;
}
class IngredientDTO {
String name;
float price;
SandwichDTO sandwich;
}
class SandwichDAO {
public SandwichDTO getSandwichWithName(String name);
public List<IngredientDTO> getSandwichIngredients(String name);
}
class IngredientDTO {
getIngredientWithName(String name)
getIngredientForSandwich(SandwichDTO sandwich);
}
{code}
Question 1 Is this correct?
Now Ingredients can have multiple Nutrional values and each type of Nutrional value can be associated with many types of ingredients. This seems to me like a many-to-many relationship and I'm assuming you would use a go-between table to map the relationship
Question 2 In the DAO pattern could this be represented as follows?
{code}
class IngredientDTO {
String name;
float price;
SandwichDTO sandwich;
List<Nutrion>
}
class NutrionDTO {
String name;
String unit;
String value;
List<Ingredients>
}
{code}
Question 3 Is 'value' placed in the NutritionDTO?
Question 4 Would I not bother to put a list of ingredients in the NutritionDTO as I could never see a reason to find all the ingredients associated with a particular nutrition type?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jaz Chana wrote:Your basically saying that a DAO should be designed about the Domain Objects (i.e. the app functionality) as opposed to the DB?
Question1 Is the above correct?
It seems to me that the getSandwichWherePrice* methods should really be in the Business Objects. It feels odd to place them here.
Now say for example I have an Order Domain Object. An order is composed of a list of Sandwiches and the order date. The Domain Object and DAO are defined as;
Question 2a Firstly the placeOrder method seems like it should go in the BO not in the DAO. But if you do this then you have nothing in your DAO to actually insert the Order into the table. What is the best way to deal with this?
Question 2b The getOrderByDate method will return an Order object. Will it also populate its nested objects? For example, will it populate the list of Sandwiches, and will it populate the each of the ingredients in each sandwich? How far will the level of nesting go?
Question 3 How would you determine whether the ingredients of each sandwich get populated? Would that involve passing in more parameters?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jaz Chana wrote:True. I think one important lesson I've learned is that there is no absolute answer, it all depends on the situation. Although design patterns are a good way to implement solutions to common occurring problems they are not an all encompassing solution. As such care must be taken to make sure that you don't overdesign you solution.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
James Boswell wrote:As a side note, I don't think it is necessary to adopt naming conventions like OrderBO or OrderDTO. These are usually objects that make up your business/domain model and may well be exposed to clients via some interface. In these cases, just stick with Order./quote]
Agreed. I add DTO if the object isn't a domain object and ONLY exists for data transfer. Maybe it is an object that contains a Customer and five random fields. Or a query object.
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |