RE: Object modeling question

[=?Utf-8?B?SmVhbi1GcmFuY29pcyBCcmV0b24=?=]

"si************@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(LineItemBusinessE ntity)
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