Object modeling question

Hi,
I have three main entities in system ............... report ,
sections , lineItem.


Requirements :
a section can be create by assembling some line items together.

a report can be created by assembling some sections together.

A administrator will have functionality to delete or add to a master
list of sections and attributes.
so in other word there are delete and add operations happening on
sections and line items out side of a context of specific report.

OK to model this....
i will have a report object. That will hold a collections of sections
and each individual section will hold collection of line items.

Something like this...


Report.Sections[i].lineItems[j].LineItemName


Now lets assume that there are two types of consumers that will using
this object model. A web applications, A windows think client
application

------------------------------------------------------------ ------------------------------
what I am trying to find out by this questions and discussion
is ..What is the best way to model this and how your object model will
change when you move from web app to windows app.

Let's take example of web application ....

Use case is delete first line item that is with in first section and
sections is inside a specific report object..

so code in my web page will look like this...
Report.Section[0].LineItem[0].Delete();

But this a web app. in most cases you will not keep your report object
on postbacks. And obviously for performance reason you are not going
to re-create the full report object again on post back and then call
delete on that ...so here is my first question..

Where would you put the method to delete the line item from report?

Would you put it as an instance method directly on report object..as
shwon below?

Report.DeleteLineItem(SectionID,LineITemId)

If yes......

But another consumer form my object model is a windows app ...where It
may be ok to keep object in memory unlike web app.
so this call may be fine as i have a fully loaded report object in
memory.
Report.Section[0].LineItem[0].Delete();

so how would you come up with common object model that works for
both ...it is possible without writing more service layers?

------------------------------------------------------------ --------------

Another use case....

Sections and line items can be deleted in the context of a report as i
described above
OR they can be deleted system wide by administrators .so if a section
or line item is not in use by any report presently admin can delete
them from the master list.

now question is what is the best place to put these delete method....

if i put them in the same sections and line items objects that I used
above
then i can write code like this....

LineItems.LoadAll()
LineItems[0].DeleteSystemWide()


but down side of this is ....they will be available in this call as
well...

Report.Section[0].LineItem[0].DeleteFromSystem();
This does not make sense because i am trying to delete system wide but
calling it on a specific report object....

So what are the solutions....

Should i use explicit interface implementation (c#)?
shoud i create separate classes and put them in separate name
spaces ..like admin.LineItem will have system wide delete function but
other line item class will not......this also is ugly because i am
creating two classes for same entity only because of this one
behavior.....


Any ideas and other ways to do it..?

Thanks
Siddharth

Re: Object modeling question

siddharthkh...@hotmail.com wrote:
> Hi,
> I have three main entities in system ............... report ,
> sections , lineItem.
>
>
> Requirements :
> a section can be create by assembling some line items together.
>
> a report can be created by assembling some sections together.
>
> A administrator will have functionality to delete or add to a master
> list of sections and attributes.
> so in other word there are delete and add operations happening on
> sections and line items out side of a context of specific report.
>
> OK to model this....
> i will have a report object. That will hold a collections of sections
> and each individual section will hold collection of line items.
>
> Something like this...
>
>
> Report.Sections[i].lineItems[j].LineItemName
>
>
> Now lets assume that there are two types of consumers that will using
> this object model. A web applications, A windows think client
> application

Good luck. The behavior and conventions of web versus fat-client (or
paper-oriented) reports are so different that making a generic
anything that serves both of them without rewrite is a big challenge
unless you pick a lowest common denominator, which limits things.

>
> ------------------------------------------------------------ ------------------------------
> what I am trying to find out by this questions and discussion
> is ..What is the best way to model this and how your object model will
> change when you move from web app to windows app.
>
> Let's take example of web application ....
>
> Use case is delete first line item that is with in first section and
> sections is inside a specific report object..
>
> so code in my web page will look like this...
> Report.Section[0].LineItem[0].Delete();
>
> But this a web app. in most cases you will not keep your report object
> on postbacks. And obviously for performance reason you are not going
> to re-create the full report object again on post back and then call
> delete on that ...so here is my first question..
>
> Where would you put the method to delete the line item from report?
>
> Would you put it as an instance method directly on report object..as
> shwon below?
>
> Report.DeleteLineItem(SectionID,LineITemId)
>
> If yes......
>
> But another consumer form my object model is a windows app ...where It
> may be ok to keep object in memory unlike web app.
> so this call may be fine as i have a fully loaded report object in
> memory.
> Report.Section[0].LineItem[0].Delete();
>
> so how would you come up with common object model that works for
> both ...it is possible without writing more service layers?
>
> ------------------------------------------------------------ --------------
>
> Another use case....
>
> Sections and line items can be deleted in the context of a report as i
> described above
> OR they can be deleted system wide by administrators .so if a section
> or line item is not in use by any report presently admin can delete
> them from the master list.
>
> now question is what is the best place to put these delete method....
>
> if i put them in the same sections and line items objects that I used
> above
> then i can write code like this....
>
> LineItems.LoadAll()
> LineItems[0].DeleteSystemWide()
>
>
> but down side of this is ....they will be available in this call as
> well...
>
> Report.Section[0].LineItem[0].DeleteFromSystem();
> This does not make sense because i am trying to delete system wide but
> calling it on a specific report object....
>
> So what are the solutions....
>
> Should i use explicit interface implementation (c#)?
> shoud i create separate classes and put them in separate name
> spaces ..like admin.LineItem will have system wide delete function but
> other line item class will not......this also is ugly because i am
> creating two classes for same entity only because of this one
> behavior.....
>
>
> Any ideas and other ways to do it..?

If you have more than about 50 and they will be changing often by
different people, consider tracking report configuration settings in a
database.

A "toy" example that sort of illustrates this can be found at:

http://www.geocities.com/tablizer/chal06.htm

>
> Thanks
> Siddharth

-T-

Re: Object modeling question

On 10 Apr, 23:26, siddharthkh...@hotmail.com wrote:
> Hi,
> I have three main =A0entities in system ............... report ,
> sections , lineItem.
>
> Requirements :
> a section can be create by assembling some line items together.
>
> a report can be created by =A0assembling some sections together.
>
> A administrator will have functionality to delete or add to a master
> list of sections and attributes.
> so in other word there are delete and add operations happening on
> sections and line items out side of a context of specific report.
>
> OK to model this....
> i will have a report object. That will hold a collections of sections
> and each individual section will hold collection of line items.
>
> Something like this...
>
> Report.Sections[i].lineItems[j].LineItemName
>
> Now lets assume that there are two types of consumers that will using
> this object model. A web applications, A windows think client
> application
>
> ------------------------------------------------------------ --------------=
-=AD---------------
> what I am trying to find out by this questions and discussion
> is ..What is the best way to model this and how your object model will
> change when you move from web app to windows app.
>
> Let's take example of web application ....
>
> Use case is delete first line item that is with in first section and
> sections is inside a specific report object..
>
> so code in my web page will look like this...
> Report.Section[0].LineItem[0].Delete();
>
> But this a web app. in most cases you will not keep your report object
> on postbacks. And obviously for performance reason you are not going
> to re-create the full report object again on post back and then call
> delete on that ...so here is my first question..
>
> Where would you put the method to delete the line item from report?
>
> Would you put it as an instance method directly on report object..as
> shwon below?
>
> Report.DeleteLineItem(SectionID,LineITemId)
>
> If yes......
>
> But another consumer form my object model is a windows app ...where It
> may be ok to keep object in memory unlike web app.
> so this call may be fine as i have a fully loaded =A0report object in
> memory.
> Report.Section[0].LineItem[0].Delete();
>
> so how would you come up with common object model that works for
> both ...it is possible without writing more service layers?

You have made a good job describing why report/section/lineitem should
not be modelled as classes. Using relational algebra, your problem
quickly disappears. Lets say we have relations as follow:

report(reportid, ...)
section(sectionid, ...)
report_section(reportid, sectionid)
lineitem(itemid, ....)
section_lineitem(sectionid, itemid)

Deleting a lineitem from a section, using relational algebra (using
SQL language) would look like this:
delete from section_lineitem where sectionid=3D? and itemid=3D?

Problem solved.

> ------------------------------------------------------------ --------------=

>
> Another use case....
>
> Sections and line items can be deleted in the context of a report as i
> described above
> OR they can be deleted system wide by administrators .so if a section
> or line item is not in use by any report presently admin can delete
> them from the master list.

delete from section where sectionid not in (select sectionid from
report_section)

> Should i use explicit interface implementation (c#)?
> shoud i create separate classes and put them in separate name
> spaces ..like admin.LineItem will have system wide delete function but
> other line item class will not......this also is ugly because i am
> creating two classes for same entity only because of this one
> behavior.....

Why do you need to create classes at all for these entities?

//frebe

RE: Object modeling question

"siddharthkhare@hotmail.com" wrote:

> Hi,
> I have three main entities in system ............... report ,
> sections , lineItem.
>
>
> Requirements :
> a section can be create by assembling some line items together.
>
> a report can be created by assembling some sections together.
>
> A administrator will have functionality to delete or add to a master
> list of sections and attributes.
> so in other word there are delete and add operations happening on
> sections and line items out side of a context of specific report.
>
> OK to model this....
> i will have a report object. That will hold a collections of sections
> and each individual section will hold collection of line items.
>
> Something like this...
>
>
> Report.Sections[i].lineItems[j].LineItemName
>
>
> Now lets assume that there are two types of consumers that will using
> this object model. A web applications, A windows think client
> application
>
> ------------------------------------------------------------ ------------------------------
> what I am trying to find out by this questions and discussion
> is ..What is the best way to model this and how your object model will
> change when you move from web app to windows app.
>
> Let's take example of web application ....
>
> Use case is delete first line item that is with in first section and
> sections is inside a specific report object..
>
> so code in my web page will look like this...
> Report.Section[0].LineItem[0].Delete();
>
> But this a web app. in most cases you will not keep your report object
> on postbacks. And obviously for performance reason you are not going
> to re-create the full report object again on post back and then call
> delete on that ...so here is my first question..
>
> Where would you put the method to delete the line item from report?
>
> Would you put it as an instance method directly on report object..as
> shwon below?
>
> Report.DeleteLineItem(SectionID,LineITemId)
>
> If yes......
>
> But another consumer form my object model is a windows app ...where It
> may be ok to keep object in memory unlike web app.
> so this call may be fine as i have a fully loaded report object in
> memory.
> Report.Section[0].LineItem[0].Delete();
>
> so how would you come up with common object model that works for
> both ...it is possible without writing more service layers?
>

The context is important in this kind of design concern : I assume there's a
lot of user and that application will evolve to add richer functionality.
My first concern would be to separate the business logic code from data
contener : the new code would look like that :
LineItemBusinessComponent.Delete(LineItemBusinessEntity)
Exposing CRUD component isn't the best thing to do because your presentation
layer have the responsability of the object graph manipulation. If you have
2 different presentation you do the job 2 times. A real service layer can
handle it for you. By the way all your CRUD operation can be handle at
service level by a single method assuming you have a "state" property in your
entities object. For example :
LineItemBE.State=EntityState.Deleted
LineItemService.Update(LineItemBE)
Now taking into consideration your graph you may not want that fine grained
service structure. You have to decide but usually you want to make a service
layer as much corsed-grained as possible. The most important reason for that
is the separation of concern : doing so force you to put all your business
logic code in the service layer. That way it's easier to isolate your
presentation layer from your presentation layer (and change the
presentation).

Since your service layer is stateless your only persistent objects are your
entities instance : make those XML serializable. You want to use bindable
capabilities of you prensentation control? Make your entities bindable.
Using a dataset as entity make sens as you don't have to code anything. All
you have to do is to make sure you have a timestamp to to manage concurency
(optimistic : on update statement add a condition on the timestamp value and
report error when the number of updated rows is 0)

That way you can use the same service layer for a web application or for a
windows application. For the web application you can use the asp.net session
to persist current transaction serialized data. In memory is correct for a
windows application.

> ------------------------------------------------------------ --------------
>
> Another use case....
>
> Sections and line items can be deleted in the context of a report as i
> described above
> OR they can be deleted system wide by administrators .so if a section
> or line item is not in use by any report presently admin can delete
> them from the master list.
>
> now question is what is the best place to put these delete method....
>
> if i put them in the same sections and line items objects that I used
> above
> then i can write code like this....
>
> LineItems.LoadAll()
> LineItems[0].DeleteSystemWide()
>
>
> but down side of this is ....they will be available in this call as
> well...
>
> Report.Section[0].LineItem[0].DeleteFromSystem();
> This does not make sense because i am trying to delete system wide but
> calling it on a specific report object....
>
> So what are the solutions....
>
> Should i use explicit interface implementation (c#)?
> shoud i create separate classes and put them in separate name
> spaces ..like admin.LineItem will have system wide delete function but
> other line item class will not......this also is ugly because i am
> creating two classes for same entity only because of this one
> behavior.....
>

Your entity are define by behaviour not by data : an object define by his
value is a "value object". Obviously in your design the master list lineitem
is a completly different entity than you report section lineitem.
Admin.LineItem would be named LineItemDefinition for clarity and you object
model could represent this by implementing a LineItem -> LineItemDefinition
association.

>
> Any ideas and other ways to do it..?

I would suggest you to read on application design : there's great on-line
free ressource on the subject.

>
> Thanks
> Siddharth
>
>
>
>
>
>
>
>

Re: Object modeling question

Responding to siddharthkhare...

Ignore Topmind and frebe. They are anti-OO P/R guys.

> I have three main entities in system ............... report ,
> sections , lineItem.
>
>
> Requirements :
> a section can be create by assembling some line items together.
>
> a report can be created by assembling some sections together.
>
> A administrator will have functionality to delete or add to a master
> list of sections and attributes.
> so in other word there are delete and add operations happening on
> sections and line items out side of a context of specific report.
>
> OK to model this....
> i will have a report object. That will hold a collections of sections
> and each individual section will hold collection of line items.
>
> Something like this...
>
>
> Report.Sections[i].lineItems[j].LineItemName

Let's not confuse things with specific 3GL syntax. At the OOA/D level
the model looks like:

[Report]
| 1
|
| R1
|
| contains
| *
[Section]
| 1
|
| R2
|
| contains
| *
[LineItem]

Since R1 and R2 are both 1:* associations, they will probably be
implemented at the 3GL level with collection classes.

> Now lets assume that there are two types of consumers that will using
> this object model. A web applications, A windows think client
> application

Display is an entirely different subject matter from the semantics of
reports. As such it is abstracted differently with its own unique suite
of rules and policies. Thus the dominant object abstractions for a GUI
would be Window/Control while the dominant abstractions for a browser
would be Page/Section.

So the display should be encapsulated in a subsystem or layer behind an
interface. Then you can swap the subsystem for the appropriate display
context while the subsystem that understands report semantics is
completely unaffected because it uses the same interface to talk to both
displays.

Re: Object modeling question

On Apr 12, 8:16 am, "H. S. Lahman" wrote:
> Responding to siddharthkhare...
>
> Ignore Topmind and frebe. They are anti-OO P/R guys.
>

You say that like its a bad thing.

> H. S. Lahman

-T-

Re: Object modeling question

topmind wrote:

>> Ignore Topmind and frebe. They are anti-OO P/R guys.

> You say that like its a bad thing.

Your fun and games might confuse newbs, who haven't learned to read
between the lines and recognize how much you like OO.

Re: Object modeling question

Phlip wrote:
> topmind wrote:
>
> >> Ignore Topmind and frebe. They are anti-OO P/R guys.
>
> > You say that like its a bad thing.
>
> Your fun and games might confuse newbs, who haven't learned to read
> between the lines and recognize how much you like OO.

I love it almost as much as I do your mama!

-T-