BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Persisting owned objects Goto page 1, 2, 3, 4  Next          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message Joao Morais Guest Posted: Wed Sep 20, 2006 5:38 am    Post subject: Persisting owned objects Hello, Let's take the following structure: TOrder = class(TMyObj) Items: ContainerOf(TOrderItem) end; TOrderItem = class(TMyObj) State: TState; end; Is it correct let the application retrieve an OrderItem without using the Order (the owner of the OrderItem)? Let's say yes, this is correct. In this case, something like this: Item := TOrderItem.Retrieve(ID); Item.State := Checked; Item.Store; might persist this change. Another sample: Order := TOrder.Retrieve(ID); Order.Item[n].State := Checked; (1) Order.Item[n].Store; (2) Order.Store; The line 1 should do nothing, the line 2 might persist all changes, in this case, one order item. How to identify if an object should or shouldn't be persisted? I thought about a 'Retrieved' flag, another idea, or am I using a mistaken approach? -- Joao Morais Back to top Joanna Carter [TeamB] Guest Posted: Wed Sep 20, 2006 8:12 am    Post subject: Re: Persisting owned objects "Joao Morais" <morais (AT) laserpress (DOT) srv.br> a écrit dans le message de news: 45108db9$1 (AT) newsgroups (DOT) borland.com... | Is it correct let the application retrieve an OrderItem without using | the Order (the owner of the OrderItem)? In the case of a Composite object like Order, you should prevent at all costs the instantiation of owned objects separately from the owner. In .NET, I design the owned class as a nested type in the owner class and I ensure that all constructors can only be called from the owning class by declaring them non-public. Likewise, it should not be possible to store instances of OrderItem separately from the Order to which they belong. | How to identify if an object should or shouldn't be persisted? I thought | about a 'Retrieved' flag, another idea, or am I using a mistaken approach? You need to maintain a Modified flag that is updated when a OrderItem changes as well as when any other property of the Order itself. Also don't forget that adding/removing items needs to change this flag. Joanna -- Joanna Carter [TeamB] Consultant Software Engineer Back to top Joao Morais Guest Posted: Wed Sep 20, 2006 3:43 pm    Post subject: Re: Persisting owned objects Joanna Carter [TeamB] wrote: Quote: "Joao Morais" <morais (AT) laserpress (DOT) srv.br> a écrit dans le message de news: 45108db9$1 (AT) newsgroups (DOT) borland.com... | Is it correct let the application retrieve an OrderItem without using | the Order (the owner of the OrderItem)? In the case of a Composite object like Order, you should prevent at all costs the instantiation of owned objects separately from the owner. Agreed, my question was about the exceptions. I have some rare cases where I need to update an specific item, independent of the owner, in this case an ID sounds better when compared with "OrderID+SuchItem". So, there are circumstances where an item retrieving might be used, or there are circumstances where I need to change my logic? :-) Quote: Likewise, it should not be possible to store instances of OrderItem separately from the Order to which they belong. Yep, also agreed. And no exception. Quote: | How to identify if an object should or shouldn't be persisted? I thought | about a 'Retrieved' flag, another idea, or am I using a mistaken approach? You need to maintain a Modified flag that is updated when a OrderItem changes as well as when any other property of the Order itself. Also don't forget that adding/removing items needs to change this flag. Yep, this one exists, but what about Items.Store? This one should persist my changes if the Items was retrieved directly, but shouldn't persist if the Items object came from the Order, its owner. Thank you for your comments. -- Joao Morais Back to top Joanna Carter [TeamB] Guest Posted: Wed Sep 20, 2006 6:15 pm    Post subject: Re: Persisting owned objects "Joao Morais" <morais (AT) laserpress (DOT) srv.br> a écrit dans le message de news: 45111b84$1 (AT) newsgroups (DOT) borland.com... | Agreed, my question was about the exceptions. I have some rare cases | where I need to update an specific item, independent of the owner, in | this case an ID sounds better when compared with "OrderID+SuchItem". When it comes to persisting owned objects as part of a composite object, there are no exceptions. Either the object is owned or it is not. Changing an item in an owned list is no different from changing any other, non-list, member of the composite class. | So, there are circumstances where an item retrieving might be used, or | there are circumstances where I need to change my logic? :-) If you are retrieving owned objects separately from the owner, then you need to change your logic. | Yep, this one exists, but what about Items.Store? This one should | persist my changes if the Items was retrieved directly, but shouldn't | persist if the Items object came from the Order, its owner. This is one of the problems of having a Store method on the business object class; it can cause all sorts of logic problems. In the example of the Order/Items classes, if you insist on having a Store method on the business class, the Item class should not derive from the same base class that has a Store method, instead the list needs to know about being owned, so that the Order will handle storage properly as part of its own Store method. I know Bob thinks differently, but this is one of the main reasons for not having any persistence code at all in the base business class, even if it is just to call the broker. Externally instigated persistence is not always desirable, as you are finding in this scenario. Joanna -- Joanna Carter [TeamB] Consultant Software Engineer Back to top Bob Dawson Guest Posted: Wed Sep 20, 2006 6:21 pm    Post subject: Re: Persisting owned objects "Joao Morais" wrote Quote: Agreed, my question was about the exceptions. I have some rare cases where I need to update an specific item, independent of the owner, in this case an ID sounds better when compared with "OrderID+SuchItem". This is very much a question of the specific problem domain(s): what is an owned object in one context may not be in another. Quote: Yep, this one exists, but what about Items.Store? This one should persist my changes if the Items was retrieved directly, but shouldn't persist if the Items object came from the Order, its owner. I'd be very leery of this. As a programmer using the object model, I'd expect that calling a method named Store would in fact do that, not do different things depending on how the target object was obtained. The routine calling Store may not have any way to know how the item came into existence. bobD Back to top Joao Morais Guest Posted: Wed Sep 20, 2006 6:47 pm    Post subject: Re: Persisting owned objects Bob Dawson wrote: Quote: "Joao Morais" wrote Agreed, my question was about the exceptions. I have some rare cases where I need to update an specific item, independent of the owner, in this case an ID sounds better when compared with "OrderID+SuchItem". This is very much a question of the specific problem domain(s): what is an owned object in one context may not be in another. With owned object I meant an object that is part of another object, like OrderItem that is owned by an Order. A reference relationship, like Address.City, City is _not_ owned by address. Quote: Yep, this one exists, but what about Items.Store? This one should persist my changes if the Items was retrieved directly, but shouldn't persist if the Items object came from the Order, its owner. I'd be very leery of this. As a programmer using the object model, I'd expect that calling a method named Store would in fact do that, not do different things depending on how the target object was obtained. The routine calling Store may not have any way to know how the item came into existence. The GUI that is assigned to that object will call Store whenever the user press the Ok or Save button. The behavior is the same with root (not owned) as well as owned objects, but only root objects will persist the Items changes in only one transaction. The problem starts in cases where I need to change an Item, perhaps verifying if the Item was retrieved, perhaps using another method that forces the storage of the changes independent of the owner... duno. Thank you, -- Joao Morais Back to top Peter Morris [Droopy eyes Guest Posted: Wed Sep 20, 2006 7:43 pm    Post subject: Re: Persisting owned objects My OPF fetches orderlines on demand through use of a special role class OrderLines = new MultiRoleMember<OrderLine>(.....); it also keeps a list of "Dirty" objects. These are created, modified or deleted object instances. -- Pete Blessed are the geek, for they shall public class GeekEarth : Earth {} ==== Audio compression components, DIB graphics controls, ECO extensions, FastStrings http://www.droopyeyes.com ==== Back to top Bob Dawson Guest Posted: Wed Sep 20, 2006 7:49 pm    Post subject: Re: Persisting owned objects "Joao Morais" wrote Quote: With owned object I meant an object that is part of another object, like OrderItem that is owned by an Order. Sure. Consider-- Pencil business. Orders contain Order items Order Items consist of a type and quantity of pencil. Now for the order entry staff, an Order Item is an owned object: but what about for the shop floor? They're only interested in the Order Lines: how many pencils of what type do they have to make? The orders don't really matter to them, just the lines. So in a manufacturing application, they might need to load and store the order items, but in completely different patterns than the order entry applications do. Why should those applications have to know about orders? That's why I said ownership might be a matter of context, rather than an intrinsic relationship. Quote: The GUI that is assigned to that object will call Store whenever the user press the Ok or Save button. The behavior is the same with root (not owned) as well as owned objects, but only root objects will persist the Items changes in only one transaction. Oh, okay. Yes, transaction context is something different. The way my model works, Order.Save will store the Order and all dirty contained lines in a single transaction. But the programmer also has the option to write Order.Lines[x].Save in which case only that item (and any owned objects it has) is saved. Quote: The problem starts in cases where I need to change an Item, The issue there is whether the owner object has any composite properties (such as counts or totals) that might be invalidated, and whether the ownership relationship places constraints on what can be changed. Creation and Deletion might not be the only aspects/methods of an object reserved to the owner. bobD Back to top Joao Morais Guest Posted: Thu Sep 21, 2006 2:13 am    Post subject: Re: Persisting owned objects Bob Dawson wrote: Quote: Pencil business. Orders contain Order items Order Items consist of a type and quantity of pencil. Now for the order entry staff, an Order Item is an owned object: but what about for the shop floor? They're only interested in the Order Lines: how many pencils of what type do they have to make? The orders don't really matter to them, just the lines. So in a manufacturing application, they might need to load and store the order items, but in completely different patterns than the order entry applications do. Why should those applications have to know about orders? That's why I said ownership might be a matter of context, rather than an intrinsic relationship. Your sample is quite perfect and demonstrate exactly one kind of issue that I have found. My model stores production order that starts in the office (Order owns Items) and the items are not processed at the same time, sometimes items that belong to different orders are processed together, and so on. Both scenarios in the same application, using the same business object model. Quote: But the programmer also has the option to write Order.Lines[x].Save in which case only that item (and any owned objects it has) is saved. This is exactly my intention, I will improve my business classes in order to reflect this behavior. Thank you. Which kind of classes (business classes, presentation classes, etc.) do you have for an object, i.e., base classes for an Order, an OrderItem, etc.? Quote: The problem starts in cases where I need to change an Item, The issue there is whether the owner object has any composite properties (such as counts or totals) that might be invalidated, and whether the ownership relationship places constraints on what can be changed. Creation and Deletion might not be the only aspects/methods of an object reserved to the owner. Yep, known issue. Thank you very much for your time. -- Joao Morais Back to top Joao Morais Guest Posted: Thu Sep 21, 2006 2:17 am    Post subject: Re: Persisting owned objects Peter Morris [Droopy eyes software] wrote: Quote: My OPF fetches orderlines on demand through use of a special role class OrderLines = new MultiRoleMember<OrderLine>(.....); it also keeps a list of "Dirty" objects. These are created, modified or deleted object instances. The issue I have found is related with the "OrderLine". I'd like to use the OID to retrieve the item, instead using the OwnerID+"LineNumber". An OID is related to the object, the LineNumber is not. -- Joao Morais Back to top Joao Morais Guest Posted: Thu Sep 21, 2006 2:28 am    Post subject: Re: Persisting owned objects Joanna Carter [TeamB] wrote: Quote: "Joao Morais" <morais (AT) laserpress (DOT) srv.br> a écrit dans le message de news: 45111b84$1 (AT) newsgroups (DOT) borland.com... | Agreed, my question was about the exceptions. I have some rare cases | where I need to update an specific item, independent of the owner, in | this case an ID sounds better when compared with "OrderID+SuchItem". When it comes to persisting owned objects as part of a composite object, there are no exceptions. Either the object is owned or it is not. Changing an item in an owned list is no different from changing any other, non-list, member of the composite class. An object or a container has much more information before a simple attribute. Because of that I wasn't considering that an owned object is "unretrievable" (oops, new word). Quote: | So, there are circumstances where an item retrieving might be used, or | there are circumstances where I need to change my logic? :-) If you are retrieving owned objects separately from the owner, then you need to change your logic. Any special reason? Quote: | Yep, this one exists, but what about Items.Store? This one should | persist my changes if the Items was retrieved directly, but shouldn't | persist if the Items object came from the Order, its owner. This is one of the problems of having a Store method on the business object class; it can cause all sorts of logic problems. In the example of the Order/Items classes, if you insist on having a Store method on the business class, the Item class should not derive from the same base class that has a Store method, instead the list needs to know about being owned, so that the Order will handle storage properly as part of its own Store method. I know Bob thinks differently, but this is one of the main reasons for not having any persistence code at all in the base business class, even if it is just to call the broker. Externally instigated persistence is not always desirable, as you are finding in this scenario. Using a Persistence.Store(Object) you might found this same issue, otoh using a class method you can hide the store method from the user. By the way I have implemented both approaches. Thank you, -- Joao Morais Back to top Joanna Carter [TeamB] Guest Posted: Thu Sep 21, 2006 3:24 am    Post subject: Re: Persisting owned objects "Joao Morais" <morais (AT) laserpress (DOT) srv.br> a écrit dans le message de news: 4511b2b6 (AT) newsgroups (DOT) borland.com... | An object or a container has much more information before a simple | attribute. Because of that I wasn't considering that an owned object is | "unretrievable" (oops, new word). My point is that owned objects have no life or context outside of the owning object, they live and die together. That is the nature of a Composite object; if you don't want that restriction, then you have not got a Composite object but an Aggregation. | > If you are retrieving owned objects separately from the owner, then you need | > to change your logic. | | Any special reason? Because the integrity of the owning object can be compromised too easily. | Using a Persistence.Store(Object) you might found this same issue, otoh | using a class method you can hide the store method from the user. By the | way I have implemented both approaches. I have been using Persistence.Store(Object) for years now, in several generations of OPF, and I have never had the problems that I would have by allowing a Store method on an owned object. | My model stores production order that starts in the office (Order owns | Items) and the items are not processed at the same time, sometimes items | that belong to different orders are processed together, and so on. Both | scenarios in the same application, using the same business object model. When looking at Order/Items and other such composite classes, it is important that you realise that the Item objects can be iterated over and used apart from their orders, but they should never be allowed to be altered in isolation. My stipulations for Item objects are : 1. They cannot be created apart from the owner. 2. They cannot be stored apart from the owner. 3. They cannot be edited apart from the owner. 4. They cannot be deleted apart from the owner. However, that does not stop you from being able to build lists of Items by iterating over selected owner objects, or by retrieving lists of read-only wrapper objects straight from the persistence. | The issue I have found is related with the "OrderLine". I'd like to use | the OID to retrieve the item, instead using the OwnerID+"LineNumber". An | OID is related to the object, the LineNumber is not. IMHO, your business classes and the business layer should have no concept at all of object identity apart from the type and memory address. I use the concept of a Data Packet to hold the fields of a class. This packet gets replaced, upon storage, with a persistable data packet which additionally holds the object ID. When retrieving objects, persistable data packets are created in the objects and this indicates that they are are already persistent, so storing them will tell the persistence to update the database rather than inserting a new record. The persistable data packet class with its ID is only available inside the persistence assembly, so the business layer is only allowed to retrieve objects based on criteria of values held in public properties. I feel it is important to emphasise that list of owned objects should be read-only, in that you cannot add/remove items from the list. The idea of read-only wrapper classes for owned objects can also help avoid developers making mistakes by editing them in isolation from their owner. Joanna -- Joanna Carter [TeamB] Consultant Software Engineer Back to top Joao Morais Guest Posted: Thu Sep 21, 2006 5:18 am    Post subject: Re: Persisting owned objects Joanna Carter [TeamB] wrote: Quote: "Joao Morais" <morais (AT) laserpress (DOT) srv.br> a écrit dans le message de news: 4511b2b6 (AT) newsgroups (DOT) borland.com... | An object or a container has much more information before a simple | attribute. Because of that I wasn't considering that an owned object is | "unretrievable" (oops, new word). My point is that owned objects have no life or context outside of the owning object, they live and die together. That is the nature of a Composite object; if you don't want that restriction, then you have not got a Composite object but an Aggregation. Agreed, but perform my approach doesn't mean that the owner and owned objects will loose their ownership, I am just taking a... shortcut. Sometimes I just need the name of my client--a simple attribute. I need to retrieve the client object in order to get this information, I do not have another way. The same occur with composite objects, I just need the Item (owned object) information regardless of the owner, but the owner continues there, won't be changed, and it can be retrieved by the internals of the OPF if necessary. Quote: | > If you are retrieving owned objects separately from the owner, then you need | > to change your logic. | | Any special reason? Because the integrity of the owning object can be compromised too easily. You have a proxy that references the owner in order to retrieve it if necessary. -- Joao Morais Back to top Peter Morris [Droopy eyes Guest Posted: Thu Sep 21, 2006 4:30 pm    Post subject: Re: Persisting owned objects Quote: The issue I have found is related with the "OrderLine". I'd like to use the OID to retrieve the item That is exactly how I would retrieve it too, so what is the problem with it? Back to top Joanna Carter [TeamB] Guest Posted: Thu Sep 21, 2006 4:57 pm    Post subject: Re: Persisting owned objects "Peter Morris [Droopy eyes software]" <pete (AT) NO_droopyeyes_SPAM (DOT) com> a écrit dans le message de news: 451277cc$1 (AT) newsgroups (DOT) borland.com... |> The issue I have found is related with the "OrderLine". I'd like to use | > the OID to retrieve the item | | That is exactly how I would retrieve it too, so what is the problem with it? Why should the business layer have to know anything about an ID that is really only necessary for storage purposes ? I really think that this ia a hangover from the old RDBMS days and need not be a part of modern OO code. Joanna -- Joanna Carter [TeamB] Consultant Software Engineer Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi OO design All times are GMT Goto page 1, 2, 3, 4  Next Page 1 of 4   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.