Hi João (Oi). As far as I understand your precept is as follows. Map Tables to Collection Classes (Table Root -> RootCollections), Map Records to Domain Classes (Root Records -> Root). What you are doing intrinsically (I Like Programmers :) is that you Collections
map to the concept of an Extent of a Class. That is, it "owns" all instances of a class (say Root). You then apply another concept. Becouse you know that the relationship between a Root and a Child is an aggregation, you decide that the child can well be a
struct as it will be created and managed by the Root. This is not a good approach without further information! 1) Why do you need the RootCollection? 2) Why do you need any other collection representing the dictomy between Table and Class Extent? 3) Why do
you need the RootChildCollection? Anyway I can provide you some short cuts. If you are thinking on using OO to the graburality of a Root or Child and use a relational database, I would advise you to use an O/R Mapper. One can be found for free in "http://ojb-net.sourceforge.net"
for you to start learning. Thona also provides one. If you are planning to build one, there is a post somewhere on this forum that as references to whitepapers and stuff targeting the build up of a Persistance Layer/OR Mapping (or just join OJB.NET team (Open
Source)). If you don't care less if your OO Objects/Model go to the granularity of Root or Child I would use an approach based on DTO/DAO (Fowler). To cut a long story short, instead of having an Root Class and a RootCollection you have a RootManager or RootService.
The UI Layer and BL (The Managers/Service) exchanges information with BL using DTO (Data Transfer Objects). There is no Root Object. In ADO.NET terms A DataSet can be amongst other things a DTO, there are other Classes on ADO.NET that can perform the pattern
player of a DTO. Your Managers (Root Manager) need to assure business rules amongst any Root Objects and their associations with Child. There is no Child Manager as you have said a relationship between a Root and a Child is of aggregation. Enjoy, Nuno
Hi Nuno (Oi também) Thanks very much for your answer. I know i have to study much more about UML and OO concepts, before debate them, but i really want to learn. In respect to the names (while this doesn't change anything, could somehow improve the feel) I
named ...Collection , maybe is better named ...List. And in ...Detail, maybe ...Info is more correct. The concept is to have an class deriving from CollectionBase and other (an struct) to have his details. The separation was an attempt to have an lightweight
(struct) and just readonly members to avoid the instantiation of an say "normal" class with business rules and/or state, when i just need an string representation and an hiden ID. This "List" going to be used in many places for say Select an Item to write
his ID has an Foreign key on others tables. Is this wrong? You wrote: "There is no Child Manager as you have said a relationship between a Root and a Child is of aggregation. " Ok, that's fine notice because otherwise i will stay loose. Write now, i have noticed
that i could have another approach, say an object that implements an interface with CRUD members, and have the BO that need CRUD behavior deriving from this one. I don't know wich is better, i think it depends from what i need. I'm also trying to model database
with ORM (visio), and that's another About O/R mappers, i'm not against, but wright now (i'm an free lancer, so any $$ needs to be well thinking) . After try some free ones (LLBGen, WEO etc.), it's easy to see the great advantadges, as speed development and
Most Important error avoid in map, and an unique development method, just to enumerate two of them. But, (i usually use BO to represent any data) there is no easy to have the write maps in a BD table that uses key composition, as in some tables that are composed
by foreign keys. I'm not saying that this is an good Sql design, just that sometimes i have to live with that. Maybe i don't have used an good O/R. But this is just an opinion, and from an not very experencied O/R developer. One thing is for shore. I want
to learn much as i can about have my next projects begining with modeling. And if i have an forum like this, for shore i will learn quickly. What's your advice: Begin with Data analysis and data flow Begin by UI design Begin by business and process analysis
Till now, i begin by some "Users feeling" show them some UI, and construct the data model. But now i have an approach as: Talk with users about the way they interact with the system. Talk again with users with some process analysis, some Use Cases(kind of),
and have an blend of all. Thanks again JCasa P.S. Sorry for some "not clear ideias, but thinking fast and write in English it's not my best"
::About O/R mappers, i'm not against, but wright now (i'm an free lancer, so any $$ needs to ::be well thinking) . Hmpf. When I was a freelancer I always got the tools I needed and made it part of my pricing calculation. I mean, every professional out there,
doctor, lawer, mechanic, is working with proefessional tools. ::After try some free ones (LLBGen, WEO etc.), it's easy to see the great advantadges, They will actually start to be REALLY obvious once you test O/R mappers. * WEO is a joke, impementaiton wise.
It needs a lot of additional work. * LLBGEN is a DAL generator, not an O/R Mapper. ::But, (i usually use BO to represent any data) there is no easy to have the write maps in ::a BD table that uses key composition, as in some tables that are composed by foreign
::keys. Ah, some "not too smart" person making db designs - it is always sad to see designs like this. They blow up the database, kill query and join performance and are extremely hard to maintain :-( You should never: * Use primary keys having more than one
column. * Actually have any meaningfull data in the key olumn ::Begin with Data analysis and data flow ::Begin by UI design ::Begin by business and process analysis I normally start with a shot process and business analysis (defining what I have to handle),
then make an OOAD cycle to get the key objects, then make the data layer and just start coding a primary prototype of the objects. Then I ggo back and start with details on use cases, state diagrams etc. I NEVER start with the UI for the functional analysis
- the UI is always slaved to the process. Not saying that some designer does not start hammering out prototypes to get a feel on how the app should look like. But the object model is always decoupled frrom the UI.
Hi Thona, Thanks for the reply. About i'm an free lancer and must have all tools, ok i agreed, BUT if you have to choose between have an O/R or have say MSDN and an notebook etc. Well, i already choose. Because bad or good i can make my work WITHOUT an O/R,
but i can't make my work without VS.net (i know i can do the same with notepad) or without machines and so on. ::LLBGEN it's not an O/R. Sorry, my mistake. Also i post that "Maybe i don't have tried any good O/R". By the way, about one month ago i tried to
get your's in the option for not comercial (sorry i don't remember the name option), but never receive the e-mail answer. Please note: I'm not saying that i don't want an O/R, or that an O/R isn't an great tool. Besides that's not the post direction. ::You
should never: ::* Use primary keys having more than one column. If you read ALL the post, you saw there: ... I'm not saying that this is an good Sql design, just that sometimes i have to live with that. ... I have to work with some already existing DB designs,
some legacy, and say them: This is not a good db design. Do other or even i'will do other, that's just not an option. If i have more work in the future maybe i could just don't accept them, but for now... ::I normally start with a shot process and business
analysis... ::But the object model is always decoupled frrom the UI. So you agree that usually the best way is a blend of all with strong emphasis on business analysis and Use cases. ::I normally start with a shot process and business analysis (defining what
I have to handle), then make an OOAD cycle to get the key objects, then make the data layer and just start ::coding a primary prototype of the objects. Ok, my problem begins when to decide what's the nouns to eliminate, and after i "could" do that, is try
to eliminate duplicate objects and/or merge others in an UML way. Sometimes end in an relationship so complex, that i'm afraid to make an trivial thing in an complex one. I supose the best way with an scennario like this is try to have an new class with the
merge members, that could be derived from the others. That's just to say that while i'm just an begginer, but this is just something that i really want to know. Could you send me any direction? Does the experiment is an best option, or do you think i should
read more about it? Or both? Thanks JCasa
::Because bad or good i can make my work WITHOUT an O/R, ::but i can't make my work without VS.net (i know i can do the same with notepad) ::or without machines and so on. Hm. How much did you pay for VS.NET? Hint: If you paid more than around 850 USD for the
large version including MSDN universal subcription you wasted money and did not ge the correct option for you. ::By the way, about one month ago i tried to get your's in the option for not comercial ::(sorry i don't remember the name option), but never receive
the e-mail answer. Hm. COULD have gone lost. Rarely happens, but we had a server issue a month ago where we lost a day's worth of emails. Reapply if you want. I just am sitting here and can give out the key immediatly. ::So you agree that usually the best
way is a blend of all ::with strong emphasis on business analysis and Use cases. Yes. The UI is last, though - well, not last. Separate. I have some other guis handling the UI and the planning normally. Someone witha larger focus on usability, nice design
etc. ::So you agree that usually the best way is a blend of all with strong emphasis on business analysis and Use cases. ::Sometimes end in an relationship so complex, that i'm afraid to make an trivial thing in an ::complex one. I supose the best way with
an scennario like this is try to have an new class ::with the merge members, that could be derived from the others. Most class hierarchies ARE complex. With the right focus you can make them easier, though. BUt compleixty is often power. We work on a SHOP
now - the product catalog alone has about 30sth tables, with 40 or 50 objects in there. Most would model this in three tables. But this is not powerfull :-)
this is a gross generalisation: > You should never: > * Use primary keys having more than one column. > * Actually have any meaningfull data in the key olumn i'll take your second statement for now... are you suggesting if you have this table for US states:
StateCode char(2) StateName varchar(50) you would actually add a (totally pointless) StateID column for a primary key?
"Write now, i have noticed that i could have another approach, say an object that implements an interface with CRUD members, and have the BO that need CRUD behavior deriving from this one. I don't know wich is better, i think it depends from what i need." I
would suggest you to read - ASP.NET Website Programming : Problem - Design - Solution http://www.amazon.com/exec/obidos/tg/detail/-/0764543865/qid=1066138762/sr=8-2/ref=sr_8_2/103-8329706-2479859?v=glance&s=books&n=507846 They follow a similar concept as yours.
But it definitly an approach that fits all scenarios. "But, (i usually use BO to represent any data) there is no easy to have the write maps in a BD table that uses key composition, as in some tables that are composed by foreign keys." Yep this can be a problem,
specially if working with legacy databases. If you can buy an O/R Mapper then choose one that allow you to deal with this issue. But think for a moment, you only have this problen when you need to work with a legacy database (extending someone else application).
But if you develop the solution from scratch then you can have one Column in each table representing the OID (Object Id). Ok, I have pointed out some interesting links about this (www.featuredrivendevelopment.com). There is also a book about the topic: A Practical
Guide to Feature-Driven Development by Stephen R Palmer (Author), John M. Felsing (Author) http://www.amazon.com/exec/obidos/ASIN/0130676152/qid%3D1066139652/sr%3D11-1/ref%3Dsr%5F11%5F1/103-8329706-2479859 This is the method that I use for software development
as I Like it. But there are others. I begin with Problem Domain Analisis - This can be your "business and process analysis". To this I usually start with some stories (XP). I get this stories from recorded meetings that I have with customers (Yes I use a tape
recorder). This also provide some information documents. From this info i define in UML may Overall Domain Model (I use Together Control Central is the best too for this IMO check www.borland.com, it geberated C# code and mantains code in sync with diagrams).
This Overall Domain Model is my base line model, it just have business objects (Order, Customer, Fligh, Plane, Ticket, Reservation etc). I do this model with the customer when possible, at least I discuss the model with him (Does this represent correctly a
Ticket? What is next after a ticket, a seat reservation in a Flight of Plane? etc etc. This forms my base line OO Model. I usually don't put all properties or methods in this baseline model. Just object associations and notes when there is complex logic going
on on associations (But it is a not). This is often called modeling by shape, that is what matter is how objects related with each other rather then their properties. If you take 1 week doing this expect 3 months of development, 2 weeks 6 months and so on.
If necessary I build some UI's just to get the fill of the process in an software application. Anyway this is just a prototyped UI. When doing Web Sites (not web applications) sometimes UI is defined up-front or in parallel with Problem Domain Analisis. After
this, I have an Overall Domain Model (base line) and I start development. I design my database incrementally as I need from the Overall Domain Model. I can do this becouse I use a O/R Mapper in Java, hopefully soon I'll use one in .NET too :) But there are
things to be taken care of first. I can go on decribing my process but is similar to the one described in the book that I've referenced. The book also stated when collaboration analisis should be done. I adapted it to my own taste and according to situation.
No in small projects, unless required by the customer I do not use "Use Cases". It is just a waste of time IMHO. In large projects, such as the ones that take 1 year or more and in teams grater then 5 then yes this is an artifact that is usefull in order not
to get lost. So what artifacts to I use? FDD - Development Process Stories - Record meetings and sometimes create simple transcripts (summaries) UML - Class Model and Collaboration Model (some time Use Cases but only when it brings some value to the discussion)
ORM - Data Modeling Documentation - provided by the customer C# and hopefully soon some O/R Mapper. "The separation was an attempt to have an lightweight (struct) and just readonly members to avoid the instantiation of an say "normal" class with business rules
and/or state, when i just need an string representation and an hiden ID. This "List" going to be used in many places for say Select an Item to write his ID has an Foreign key on others tables." Take an Order and its Order Lines (Order [1:N] OrderLine ), are
you saying that you will never SELECT All Orders of a given Product?. I'm taking your example as abstract pattern. As for implementation of business rules using OO Paradigm and Business Objects that represent Objects in the Problem Domain read: "Streamlined
Object Modeling: Patterns, Rules, and Implementation by Jill Nicola (Author), Mark Mayfield (Author), Mike Abney (Author), Michael Abney" http://www.amazon.com/exec/obidos/tg/detail/-/0130668397/qid=1066141487/sr=8-1/ref=sr_8_1/103-8329706-2479859?v=glance&s=books&n=507846
If you get more interest in modeling. Try modeling with color, facilitating the communication with the customer: "Java Modeling In Color With UML: Enterprise Components and Process by Peter Coad (Author), Eric LeFebvre (Author), Jeff De Luca (Author)" http://www.amazon.com/exec/obidos/tg/detail/-/013011510X/qid=1066141562/sr=1-1/ref=sr_1_1/103-8329706-2479859?v=glance&s=books
Enjoy Nuno PS: C# is very similar to Java. If you know C% you will not have any defficulties in reading the Java code presented in the Bools. Enjoy, Nuno
with the id you can reference each row from another table with a INT as foreign key. with state code you would require a varchar... ok, in this example, char(2) does not take much space, but you loose flexibility, as e.g. we in austria would require a char(3)
for a state... id's for references are always easy, especially for the web you don't have to escape the values for url_encoding etc.... and you still have the option to declare your stateCode Column as unique... thoean
Well, if you ahve a table of US STates you have other problems :-) YOu are too US centric. But yes, I would add such a table, in this case propably as short. Using things like country codes is one of the rare case this could actually work, as this is an ISO
standard (like countrycodes as ISO2), but normally stuff like a social security number ust make a dead stupid primary key (besides being illegal, in case of a SSN).
Hi again, Thona :Hm. How much did you pay for VS.NET? Hint: If you paid more than around 850 USD for the large version including MSDN universal subcription you wasted money and did not ge the correct option for you. I have MSDN licence for cience and high-schools,
about 1000 Euros. : Hm. COULD have gone lost. Rarely happens, but we had a server issue a month ago where we lost a day's worth of emails. Reapply if you want. I just am sitting here and can give out the key immediatly. Well, i'm very interested, but not very
urgent because of the $$. I have (yesterday) bought an Presario X1010, very expensive but i'm very happy. The screen is 16:9 format. Some strange when saw my apps running, but high quality image. So, i could get the demo and maybe next month we will talk again.
Do i take the normal steps? I remember have seen in your last posts that you preparing an last version. Already finished? ::BUt compleixty is often power. We work on a SHOP now - the product catalog alone has about 30sth tables, with 40 or 50 objects in there.
Most would model this in three tables. But this is not powerfull :-) That's good news to ear. My afraid to transform something simple say your example 3 in 30 is always one thing that before do it to an finished app that WORK with all requests for the moment...
i'm shore you know what i mean. But then, usually i could resist to do something when revising old code. Do you think Visio is enough to start with?
nbplopes
Participant
1745 Points
349 Posts
Re: Pencil and paper design
Oct 14, 2003 09:36 AM|LINK
João Ca...
Member
500 Points
100 Posts
Re: Pencil and paper design
Oct 14, 2003 11:21 AM|LINK
thona
Member
20 Points
2923 Posts
Re: Pencil and paper design
Oct 14, 2003 12:03 PM|LINK
João Ca...
Member
500 Points
100 Posts
Re: Pencil and paper design
Oct 14, 2003 01:45 PM|LINK
thona
Member
20 Points
2923 Posts
Re: Pencil and paper design
Oct 14, 2003 02:12 PM|LINK
m7
Contributor
4225 Points
843 Posts
Re: Pencil and paper design
Oct 14, 2003 02:23 PM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Pencil and paper design
Oct 14, 2003 02:32 PM|LINK
thoean
Member
405 Points
81 Posts
Re: Pencil and paper design
Oct 14, 2003 02:35 PM|LINK
thona
Member
20 Points
2923 Posts
Re: Pencil and paper design
Oct 14, 2003 02:35 PM|LINK
João Ca...
Member
500 Points
100 Posts
Re: Pencil and paper design
Oct 14, 2003 02:37 PM|LINK