lampy24
asked on
Design Question
Hi,
I am currently designing a business app and I have a few questions. For some background, my application is split up into UI layer, Business Layer and Data Layer. It is a multiform app that the user selects certain options from a backend db and adds other input. It uses the user input and applies business rules (calculations...) to the data. Then it displays a report and saves the application data to file (xml) and later down the road it might save to a db. I am having a problem designing the business layey (business entities). I am trying to decide how to save the user input (during the life of the application) especially since the user input will be needed in different areas of the program and it will need to be saved as a xml file and have the capabilities to be saved to a db (future possibility). I am toying with the idea of using typed datasets however one area that typed datasets cannot meet is the criteria (user data) is dynamic in the fact that it changes based on user input (options for certain choices). I would have to manually add each column and row; it is not that bad. However, the typed datasets are great for either saving to a xml file or db. I decided against custom business entities because why reinvent the wheel that typed datasets have. So, my first question are typed datasets the norm? Any other choices?
I am also looking for a design reccomendation on how to use the business entities. I am going to create 3 to 4 business entities that will model the user data into logical categories (tables). Since, these entities will be needed throughout the application is it better to create a main business entitiy that has static members of each business entity and then when I want to save to file I can make this class serializable or put logic to save each business entity to db (calling the right business object for each business entity? Or when I need access to each entity I just call the main entity to get the data. Is this a good idea? I am just a bit confused on the best approach, before .Net I used a temp file for user data serialization however I am looking for a .Net approach with typed datasets/business entities.
Thanks and any ideas would be appreciated!
I am currently designing a business app and I have a few questions. For some background, my application is split up into UI layer, Business Layer and Data Layer. It is a multiform app that the user selects certain options from a backend db and adds other input. It uses the user input and applies business rules (calculations...) to the data. Then it displays a report and saves the application data to file (xml) and later down the road it might save to a db. I am having a problem designing the business layey (business entities). I am trying to decide how to save the user input (during the life of the application) especially since the user input will be needed in different areas of the program and it will need to be saved as a xml file and have the capabilities to be saved to a db (future possibility). I am toying with the idea of using typed datasets however one area that typed datasets cannot meet is the criteria (user data) is dynamic in the fact that it changes based on user input (options for certain choices). I would have to manually add each column and row; it is not that bad. However, the typed datasets are great for either saving to a xml file or db. I decided against custom business entities because why reinvent the wheel that typed datasets have. So, my first question are typed datasets the norm? Any other choices?
I am also looking for a design reccomendation on how to use the business entities. I am going to create 3 to 4 business entities that will model the user data into logical categories (tables). Since, these entities will be needed throughout the application is it better to create a main business entitiy that has static members of each business entity and then when I want to save to file I can make this class serializable or put logic to save each business entity to db (calling the right business object for each business entity? Or when I need access to each entity I just call the main entity to get the data. Is this a good idea? I am just a bit confused on the best approach, before .Net I used a temp file for user data serialization however I am looking for a .Net approach with typed datasets/business entities.
Thanks and any ideas would be appreciated!
I like to recommend following article which deals how to represent Business Entity Components and especially it deals with representing Business Entities as a Typed DataSet.
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp)
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp)
ASKER
wile_e_coyote,
Thanks for the post. How do you suggest creating the untyped dataset based on user input? There is not db structure to base on! I thought I owuld use typed dataset because at design time I know the 95% of the entity structure and at runtime I have no direction. I guess I could create xml files that represents the structure of each dataset. Isn't that similiar to having a typed dataset?
Also, the reason I thought about having a single main entity(nothing more than a container class for each business entity) with each business entity as a member. I thought it would be easier to save to one xml file. I see your point of not having one entity however how easy is it to save each business entity to one xml file?
Thanks again
Thanks for the post. How do you suggest creating the untyped dataset based on user input? There is not db structure to base on! I thought I owuld use typed dataset because at design time I know the 95% of the entity structure and at runtime I have no direction. I guess I could create xml files that represents the structure of each dataset. Isn't that similiar to having a typed dataset?
Also, the reason I thought about having a single main entity(nothing more than a container class for each business entity) with each business entity as a member. I thought it would be easier to save to one xml file. I see your point of not having one entity however how easy is it to save each business entity to one xml file?
Thanks again
perhaps I am oversimplifying, but wouldn't it be easier to simply serialize your object out to a file? The file could have a user name and a timestamp as the filename, then each user could have their own file on the server. Assuming you want to have clean data every day you could simply delete all files in a directory every night/week/month. There is also a method to SerializeXML as well.
As for creating a typed data set....
eh... I have never found a use for them personally, but I have read a bit about them. There are people out there who think it is the absolute best method to use. I guess I just haven't played with them enough to have an opinion one way or another.
However, even you do create a typed data set I would still encourage you to serialize your data. Serialization is absolutely the best way to persist data in a small, fast, lightweight fashion.
ASKER
The real issue is at design time I do not know what all the data (dynamic based on user input) so I thought datasets (typed or not) would work in my case since I can just add this data at runtime. What do others do when trying to persist user data (user input) from the UI and business data (business rules - Calculations on user data)? Do you use custom classes and pass in data and then serialize data and when the app needs it deserializes the data? Or do you create a static reference to your persisting object?
Thanks for the posts
Thanks for the posts
Personally I create custom classes and serialize and deserialize the classes as needed.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
wile_e_coyote,
Thanks for the post. That is the real problem I am having: saving multiple entities to the same file. Eventually, we will save the entities to a sql db but for now we want to save to a xml file which would match our table structure. Thinking about this some more I could create one entity instead of splitting it up into multiple entities. I would have multiple tables in the entity. Or I could just keep it split up and create a untyped dataset and merge all the entities (datasets) into the one at save time. This is alot of overhead and it would force me to have my business entities of typed and untype dataset or custom classes that creates a dataset of the data. What do you think about this?
Thanks
Thanks for the post. That is the real problem I am having: saving multiple entities to the same file. Eventually, we will save the entities to a sql db but for now we want to save to a xml file which would match our table structure. Thinking about this some more I could create one entity instead of splitting it up into multiple entities. I would have multiple tables in the entity. Or I could just keep it split up and create a untyped dataset and merge all the entities (datasets) into the one at save time. This is alot of overhead and it would force me to have my business entities of typed and untype dataset or custom classes that creates a dataset of the data. What do you think about this?
Thanks
When you implement the database will you be persisting to a single table or multiple tables? If the latter, then you should save each entity to a separate file, since you'll be doing an analogous operation (ie saving each entity to a separate table) when you implement the database.
If you are saving multiple entities to a single table, then I'm not sure I like your database design :-) (or maybe I'm misinterpreting what you mean by "entity")
If you are saving multiple entities to a single table, then I'm not sure I like your database design :-) (or maybe I'm misinterpreting what you mean by "entity")
ASKER
No it will save to multiple tables. Why can't I create one untyped dataset and just pass in the other tables (entities) and merge each table into one dataset? I know there would be some overhead however this would just be fix for one xml file. I really rather have one file so, I do not want to have to map files to each other. This application is a work order where each file represents an order.
Thanks again
Thanks again
ASKER
I decided not to save to file and implement saving to a db. This will make it much easier to save. Back to my main question is how to implement the business entities. I will need the data inputed by the user and db values retrieved based on user input throughout the app. I want to use untyped datasets to save the data however since I need the data in other areas (Business Objects). I was thinking of having custom classes with properties to retrieve the data and then each custom class saves (CRUD) the data to the database. Any ideas?
Thanks
Thanks
We have an app that uses exactly the architecture you're proposing. The big issue is maintainability: everytime you add or remove a column you also have to update your custom class. If your schema is static, then you have no worries. Ours is dynamic enough that we decided to build a code-generator which generates the custom class based on the database schema.
ASKER
Thanks for the post. Since, I need the data throughout my program I was thinking about making the member static instead having to pass the class around. What do you think?
Thanks
Thanks
Static will work but most OO developers would recommend that you implement it as a singleton.
lampy,
There is a lot of justification for using XML Dataset, don't be so quick to switch to DBs. The main reasoning being that anyone else can easily write a program to re-use this data without being shown anything more than the file, whereas hooking into a db requires more work.
It is really a single day process to write code to house all of the persistence of these tables, provided they are not very complex.
Typed Dataset are extremely useful insofar as they are in fact typed. However, as you pointed out, they are not very extensible. I have found that they typing helps a little during programming, but not enough to forgoe easy changes at a later date.
You should of course, be wrapping all of the data so the back-end doesn't matter. In which case, typing is only a minor help. If your datasets are going to get very large with many queries being made, then you should want to go with DB, since XML will be slower. However, even modest file sizes 10-50 megs won't be that bad with XML.
as for the business models, I would recommend structure your code such that each model implements a business interface that has all of the calculation function calls. these would then be singletons that you pass around. static calls would also work in this case if you just set the s_currentBusinessModel = something and call all of the calculations on s_currentBussinessModel .
As for persisting the model, you can simply serialize to XML or Binary, I wouldn't think they would be so complex as to justify a database, but I could very well be wrong.
There is a lot of justification for using XML Dataset, don't be so quick to switch to DBs. The main reasoning being that anyone else can easily write a program to re-use this data without being shown anything more than the file, whereas hooking into a db requires more work.
It is really a single day process to write code to house all of the persistence of these tables, provided they are not very complex.
Typed Dataset are extremely useful insofar as they are in fact typed. However, as you pointed out, they are not very extensible. I have found that they typing helps a little during programming, but not enough to forgoe easy changes at a later date.
You should of course, be wrapping all of the data so the back-end doesn't matter. In which case, typing is only a minor help. If your datasets are going to get very large with many queries being made, then you should want to go with DB, since XML will be slower. However, even modest file sizes 10-50 megs won't be that bad with XML.
as for the business models, I would recommend structure your code such that each model implements a business interface that has all of the calculation function calls. these would then be singletons that you pass around. static calls would also work in this case if you just set the s_currentBusinessModel = something and call all of the calculations on s_currentBussinessModel .
As for persisting the model, you can simply serialize to XML or Binary, I wouldn't think they would be so complex as to justify a database, but I could very well be wrong.
ASKER
Thanks for all the posts. Sorry I have not given points - I have been out of town. FYI - I decided to use a combination of datasets and custom classes. I use custom classes for persisting the data to the database and i use untyped datasets for passing data between business objects (gives me the power to add new values (rows) at runtime (dynamic options)). I have one last question. What do u do for table mappings? I am looking at using a xml file for this.
Thanks
Thanks
There are a lot of things you can do to help out with table mappings.
If you are using SQL server you can simply query your table's structure using a command like:
Select * from syscolumns where id in (Select id from sysobjects where name = '<TABLE>')
This query returns all of the column names (and column properties) for the table that you choose. Some of those statistics include datatypes, autovalues, field lengths, etc.
This is what I use in order to create my custom classes.
We wrote a code generator that generates methods which can either 1) copy the properties of a custom object to a stored procedure parameters (for inserts, updates or deletes) or 2) copy the columns of a DataReader to the properties of a custom object.
ASKER
I am still struggling with the idea of data containers. I have took your advice and used custom classes to save my app data to a database. Now my problem is passing data retrieved from the database that is based on user input and will be used in multiple business objects. It can be a custom classes because this data is dynamic and will not be known at runtime. I was thinking of using a main untyped dataset and when the app goes out and retrieves data based on user input - just add the new data tables to the main untyped dataset. I would like to have one data table with all the data - I just need it to during the life of the app so the structure of data does not need to match the db. ANd for my Business objects it would be easier for it to be a data table. I was also thinking of using a hashtable however part of my application is a reporting engine that works well with a datasets. Any ideas?
Thanks
Thanks
ASKER
Thanks for all your help. I decided to use custom classes to persist my data and use a hashtable as a data container inside my app.
1. they allow design-time binding of form controls to the dataset's datacolumns
2. they expose the datacolumns as properties, which provides a more efficient way of accessing the data than by using the indexer (ie. DataSet.ColumnName is more efficient than DataSet.DataTable["ColumnN
Therefore, in answer to your first question, I would recommend that you use untyped datasets which provide all of the functionality of a typed dataset (ie. serialization, easy persistence to a db, etc) except for the 2 items noted above. You will also be able to add columns "on the fly" to an untyped dataset.
Regarding your second question, I would recommend using separate entities rather than a single main entity. I think it makes for a more maintainable app, but that's just my opinion.