3tier - dataflow

[jogisarge]

hello, i try to learn the 3tier-architecture But there are a few question: 1.How can i fill a datagridview in my UI. the grid should be filled by a dataset. user can change the data in the grid. How could this be realized ? a) The DAL returns a dataset to the BAL and the BAL forwards the dataset to the UI? b) The DAL returns a datatable to the BAL and the BAL creates a dataset and forwards it to the UI? c) other? 2.How can i update the database ? That should be realized with the DataAdapter, right? bye jogi

[Thomas Weller 0]

The whole thing of separating the layers is about not letting the UI know that there is such a thing as a datalayer and vice versa. Thus, your question (the grid should be filled by a dataset) is misleading. A grid shouldn't be aware of the concept 'dataset' at all. (I know that it is not always done this strict way, but then it is no proper 3tier architecture...) Rather you have your BAL communicate with the DAL exclusively, and your UI is only allowed to talk with the BAL, not with the DAL. Example: You have a db table, say CUSTOMERS. In your BL, you have a related business object, a Customer class. Additionally you have a class that gives the illusion of an in-memory collection of all customers, say CustomerRepository, that is used to access certain Customer objects or collections of them on demand. Internally, this CustomerRepository is using the DAL to persist your data. The DAL is the layer used for mediating between your CUSTOMERS table and the Customer class. Now, in your GUI, you can fill your grid with Customer instances instead of dataset rows. Regards Thomas

www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.

[jogisarge]

Hi Thomas, thanks for your help. I made it like you described. Now i have a list(List) of customers (like your example) in my grid. How can i write the changed Data from the grid back to the DAL ? Can i Update the grid in one Step ? Or do i have to get the changed rows and update every changed row per code ? bye jogi

[Thomas Weller 0]

Well, I assume that your grid and your Customer instances are automatically kept in sync all the time (you can achieve this by simply databinding your Customers collection to the grid - each property to its respective column). So it's a matter of how to persist the changed/new/deleted Customer instances from the BL to the db. The DAL is responsible for updating/creating/deleting Customers, the BL has to maintain the necessary information. There are two approaches to the question How is the necessary information hold?: (1) It can be stored in the business object itself or (2) the Repository can maintain respective lists. In the first case the business objects would have each a Dirty and a Deleted property (New can normally be seen from the fact that new objects have no ID yet...), in the second the respective repository would maintain lists of changed/new/deleted objects. The second approach is the cleaner one, since in this case the business objects do not expose persistence related stuff at all. It's also faster, if you have to manage very large lists. So, in our example, it would go like this: The user changes sth. in the grid, e.g. a Customers firstname from 'John' to 'Mike'. This changes the related Customer instances Firstname property respectively. Inside this property setter, either an internal Dirty-Flag is set to true (1) or the Customer instance tells its Repository that it has been changed (2). Now the User clicks on the Save button, which would result in a call to CustomerRepository.SaveAll or sth. similar. SaveAll would cause the repository to go through the list of Customers and save/delete/create all as indicated by their respective properties (1), or the repository would ask its own internal lists to do this (2). The repository then calls the DAL to do the persistence stuff, wrapped inside a db transaction. Regardless of the exact implementation details, the UI simply calls SaveAll, and that's it. It is totally agnostic of what goes on behind the scenes. (Often, an object-relational mapper (like e.g. NHibernate or MS Entity Framework, to name just two) is used to automate all this persistence stuff like keeping DB and BL in sync, caching etc. Admittedly, it's a bit complicated to learn, but it pays. This article on CP might give you a good ove