Object modeling question

[siddharthkhare]

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.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

 

[topmind]

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.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-

 

[frebe]

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.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?

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=? and itemid=?

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

 

[Jean-Francois Breton]

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.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.

 

[H. S. Lahman]

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.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.

<aside>
You expressed a concern about not having objects for a browser UI. That
should not matter. All display subsystems need to talk to the outside
world somehow and that will vary with the display paradigm (e.g., the OS
Window Manager for a GUI or a TCP/IP port for a browser). The display
subsystem will have objects but when the display is actually rendered
that will be done through sending messages to somebody outside the
application using the protocols and conventions unique to the UI.

IOW, the job of the UI subsystem is to convert the problem solution view
to the view of the display paradigm de jour. To do that it has to
abstract the display paradigm with objects properly. But those objects
are essentially just data holders to facilitate formatting the control
messages that must be issued to the hardware or OS.

Also note that when one abstracts the display *paradigm* properly, it
should be possible to reuse that subsystem in any application where that
particular display paradigm is needed. All that changes are the data
values and the initialization of the UI objects. The data comes from the
user or the problem solution, so all one needs is identity mapping
between the UI objects and the problem domain entities, which can be
provided in external configuration data for the particular application.

The part of the application dealing with Report semantics would be
unchanged. Each display paradigm would have its own subsystem that
modeled that particular paradigm, as indicated above.

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?

The delete should be a method of the relevant collection object.

However, whenever different subsystems operate on the same data, they
need to be synchronized. That usually comes "for free" with UIs since
the user is the one that will probably trigger the deletion by an action
in the UI. So all the UI subsystem needs to do is notify the subsystem
with the Report semantics about what the user did, which is its job in
the first place. The subsystem with Report semantics would implement the
response to that announcement in the relevant collection object, in this
case for R2. IOW, the interface to the subsystem with the Report
semantics will re-dispatch the UI's message to the appropriate
collection class method.

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();

This is exactly why one should break up the application and modularize
it around subject matters. The subsystem interfaces decouple the
implementations so the Report semantics needs to know nothing about the
actual UI implementation.

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

The layered approach works for CRUD/USER applications so it is the way
RAD IDEs work. However, for more complex problems one needs a 2D
skeleton rather than a 1D skeleton. Modularization of the application is
basic design to ensure maintainability.

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

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....

It goes in the same place. All you have added is the need to validate
the user's privileges before actually invoking the deletion. That
requires two things:

(1) you have to know who the user is.

(2) it needs to be done between the time the user triggers the action
and before the collection delete method is invoked.

Deciding where and how to validate privilege is a basic design issue
that depends on a whole lot of different things. Unfortunately there may
be conflicting considerations. For example, it is usually good practice
to do user input checking as close to the user as possible (i.e., in the
UI subsystem). OTOH, it is hard to rationalize that privilege validation
is part of a specific display paradigm subject matter. (If privilege
checking is fairly complicated, such as feature-based licensing, it
might warrant its own subsystem.) Making such trade-offs will depend on
a holistic view of the overall requirements and implementation
technologies. So there is no "best" answer.



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
(e-mail address removed) for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

 

[topmind]

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-

 

[topmind]

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-