Re: Singular vs. Manager Business Layer Classes
From: headware (headware_at_aol.com)
Date: 06/23/04
- Next message: Piers: "RE: UI Validation in NTier"
- Previous message: bredd: "web apps"
- In reply to: headware: "Singular vs. Manager Business Layer Classes"
- Messages sorted by: [ date ] [ thread ]
Date: 22 Jun 2004 22:34:15 -0700
I appreciate all the replies. After reading a bit of the book
"Patterns of Enterprise Application Architecture" by Martin Fowler I
noticed a pattern called Table Module that basically describes what
we're doing. The pattern says that there are no classes that represent
single objects. The classes are based off the tables in the database
therefore they all represents sets of data. So I guess the answer is
that you only have People classes and no Person class. Which makes
sense since as we get more into the project and start writing code
it's becoming pretty obvious that there's really not much need for the
singular type classes. I'm still worried about having a few really
large interfaces but maybe there are some other patterns I haven't
encountered that can help with that.
Dave
headware@aol.com (headware) wrote in message news:<e3f4b0ae.0406152110.603a83ca@posting.google.com>...
> I'm helping to design a 3-tiered architecture for the first time and
> we have an issue that we're looking for advice on.
>
> In our application, we work with a particular type of object a lot.
> For the sake of argument, let's say that we're writing an application
> that simply stores data about people. Logically you would think that a
> business tier class called Person would be called for. However, as we
> design things, it is seeming more and more like we don't need a class
> called Person but rather a class called People that lets you work with
> a single person or many people.
>
> For example if you want to have a DataGrid that displays all people
> living in California you would need a business layer class that had a
> method like "GetAllPeopleFromState(string state)". It doesn't make
> sense to have that method in a class called Person since it pertains
> to many people. For the same reasons, methods like
> "AddNewPerson(string name, int age, string phone)" would have to go in
> the People class and not in the Person class. Methods like
> "UpdatePerson(string SSN)" or "DeletePerson(string SSN)" could go into
> the Person class but then you have two classes that work on people
> type objects. That seems like bad design to me. We could go solely
> with the People class and nix the Person class but this also doesn't
> seem like good design since it doesn't really model the real world
> that well. Plus it tends towards having one giant class instead of
> more, smaller classes, which could hurt modularity and reuse. How do
> people normally deal with this issue?
>
> Thanks,
> Dave
- Next message: Piers: "RE: UI Validation in NTier"
- Previous message: bredd: "web apps"
- In reply to: headware: "Singular vs. Manager Business Layer Classes"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
