Business Object Structure
-
I've been trying to figure out what would generaly be a better course of action regarding Business objects. I have a few options, and i was just wondering what methods other people use, and in what situations. 1) A Data Object with a support object for manipulating data. 2) A Data Object with integrated data manipulation. 3) A Data object with a supporting data manipulation object that can be injected into the Data Object and used to manipulate Data via proxied functions. (A kind of hybrid, almost like injecting a DataAdapter.) Tris
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
I've been trying to figure out what would generaly be a better course of action regarding Business objects. I have a few options, and i was just wondering what methods other people use, and in what situations. 1) A Data Object with a support object for manipulating data. 2) A Data Object with integrated data manipulation. 3) A Data object with a supporting data manipulation object that can be injected into the Data Object and used to manipulate Data via proxied functions. (A kind of hybrid, almost like injecting a DataAdapter.) Tris
------------------------------- Carrier Bags - 21st Century Tumbleweed.
I would recommend keeping the object neutral with regard to source. So seperate out the population mechanism such that it can come from multiple datasources if you have that requirement. I wouldn't couple it with a dataset for instance. For instance we have to support loading from an app server, oracle, or mssql. As far as whether it should be flyweight or not really has more to do with your application. Even for the flyweight pattern I embed some transformations. Like say dates, int verses string, etc. For bulk operations I usually put together a helper class that knows how to use them. Which would usually be tied to some other mechanism like a database, or app server. Is that kinda what you were looking for? I guess it depends on what you mean by data manipulation.
This statement was never false.
-
I would recommend keeping the object neutral with regard to source. So seperate out the population mechanism such that it can come from multiple datasources if you have that requirement. I wouldn't couple it with a dataset for instance. For instance we have to support loading from an app server, oracle, or mssql. As far as whether it should be flyweight or not really has more to do with your application. Even for the flyweight pattern I embed some transformations. Like say dates, int verses string, etc. For bulk operations I usually put together a helper class that knows how to use them. Which would usually be tied to some other mechanism like a database, or app server. Is that kinda what you were looking for? I guess it depends on what you mean by data manipulation.
This statement was never false.
Hi Chris, I've never really liked using datasets as a whole, but i do find the Tables and Adapters immensley useful stand alone (Although there is exactly zero chance of a DB change). By Manipulation, i mean the functions that wrap execution of the SQL. As a concrete example, i've tried it a few ways, but i'll go over them briefly and see if that clarifies anything. 1) An Account data object that contains just the fields, and an account manager object that can handle inserting, updating, enabling / disabling etc. 2) An account data object with the fields AND the functions for handling inserting, updating, enabling / disabling etc. 3) An account data object with the fields AND the functions for handling inserting, updating, enabling / disabling etc, with a support class which has the same functions (like example 1) and is required inside the data object for the data object's functions to work. Basicaly the functions proxy to the internal objects method calls. I've tried all of them, and unfortunately, its left a bit of a mess in some of my code as i couldn't make up my mind what was the best way to go about it. I lean towards option 1, but think that 3 has some potential if done right. T
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
Hi Chris, I've never really liked using datasets as a whole, but i do find the Tables and Adapters immensley useful stand alone (Although there is exactly zero chance of a DB change). By Manipulation, i mean the functions that wrap execution of the SQL. As a concrete example, i've tried it a few ways, but i'll go over them briefly and see if that clarifies anything. 1) An Account data object that contains just the fields, and an account manager object that can handle inserting, updating, enabling / disabling etc. 2) An account data object with the fields AND the functions for handling inserting, updating, enabling / disabling etc. 3) An account data object with the fields AND the functions for handling inserting, updating, enabling / disabling etc, with a support class which has the same functions (like example 1) and is required inside the data object for the data object's functions to work. Basicaly the functions proxy to the internal objects method calls. I've tried all of them, and unfortunately, its left a bit of a mess in some of my code as i couldn't make up my mind what was the best way to go about it. I lean towards option 1, but think that 3 has some potential if done right. T
------------------------------- Carrier Bags - 21st Century Tumbleweed.
I would opt for number 1. It leaves the data objects light weight in case you need to marshall them, or bind them to a web page etc. And in the case where maybe the database itself won't change, the schema might, and if you need to handle that case, then the places where the data objects are bound to controls etc, nothing has to change. You just change it in the data layer in the helper class. [edit] I usually use DataReaders and populate a custom collection instead of DataTables and DataAdapters. But the DataTable is nice if you need a filtered view in addition to the standard one. [/edit]
This statement was never false.
-
I would opt for number 1. It leaves the data objects light weight in case you need to marshall them, or bind them to a web page etc. And in the case where maybe the database itself won't change, the schema might, and if you need to handle that case, then the places where the data objects are bound to controls etc, nothing has to change. You just change it in the data layer in the helper class. [edit] I usually use DataReaders and populate a custom collection instead of DataTables and DataAdapters. But the DataTable is nice if you need a filtered view in addition to the standard one. [/edit]
This statement was never false.
Hi Chris, Thanks for that, i think that's pretty much what i ended doing, using the DataRow as a data object, and the DataAdapter as the actual SQL wrapper. I would be happy to use a DataReader, but find that i'd have to write reems of code to support it, and generate the queries and parameters etc. I'm guessing you use some kind of code generator for generating your parameterised SQL / Stored Procs? Did you write your own or go 3rd party? If you wrote your own, How do you enforce field constraints (i.e. max string length 40) in the data object? Similar to the way a data row does. If you went with the 3rd party route, what would you recommend? Cheers Tris
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
Hi Chris, Thanks for that, i think that's pretty much what i ended doing, using the DataRow as a data object, and the DataAdapter as the actual SQL wrapper. I would be happy to use a DataReader, but find that i'd have to write reems of code to support it, and generate the queries and parameters etc. I'm guessing you use some kind of code generator for generating your parameterised SQL / Stored Procs? Did you write your own or go 3rd party? If you wrote your own, How do you enforce field constraints (i.e. max string length 40) in the data object? Similar to the way a data row does. If you went with the 3rd party route, what would you recommend? Cheers Tris
------------------------------- Carrier Bags - 21st Century Tumbleweed.
Alot of coding. My system is on the mobile device. PocketPC. So, for my application I also have to generate the database. So I use a set of table descriptions that define the database to populate the business objects with. I use a table description to generate the select sql then populate the businss object from a reader into a generic collection. Validation of data is done at the form level. Since most of my processing derives from the user and the UI. Type constraints haven't really affected me much.. yet. I don't enforce anything in the data object. Its all either in the UI or in the DB.
This statement was never false.
-
Alot of coding. My system is on the mobile device. PocketPC. So, for my application I also have to generate the database. So I use a set of table descriptions that define the database to populate the business objects with. I use a table description to generate the select sql then populate the businss object from a reader into a generic collection. Validation of data is done at the form level. Since most of my processing derives from the user and the UI. Type constraints haven't really affected me much.. yet. I don't enforce anything in the data object. Its all either in the UI or in the DB.
This statement was never false.
I suppose what drives me nuts is when i forget enforcing on the front end, that gets dumped to an BO, and then on inserting into the DB, the data is out of range and the app falls over. Makes it a mission to figure out where it went wrong, which would be when the value was set. They use a truncation method where i am atm, which drives me up the wall because there's NO length checking anywhere. ><
------------------------------- Carrier Bags - 21st Century Tumbleweed.