>I have yet two questions: > >1) DataModules. In delphi there is some kind of units, similar to forms, >which i can use for placing non visual components such as connections, >transactions, datasets and datasources. So i can place all my datasets >inside this datamodule and use it where i need. It's very convenient. >Than a few forms can use same datasource + dataset and all controls >synchronize automatically by delphi. > >Imagine you have two forms: Goods and Sales. >When you insert or edit sales you should select a good to sale, so Grid
>in table Goods and DropDownList in form Sales linked with same >datasource/dataset which placed in datamodule. >So grid on Goods form and DropDownList on sales form always show same >records. >Than if i open both forms Goods and Sales and change goods in goods form >than this changes immediately shows in sales drop down list because of >delphi synchronize it. > >What i can use in ADO.NET instead of that? In the .net world we use delegates and events instead of modules (although VB has project wide modules). The data table, collections, and what not are disconnected from the database. This gives 10 fold increases in scalability and connected users. You can use events to trigger methods of functions to populate you dataset on the other form(s). Personally I avoid the black box, wave a magic wand approach. >2) Datasets in delphi are clever. When i call DataSet.Open() than >dataset fetch only records which need controls for display (or 1 record >if no controls linked). >For example i have form Goods with datagrid. In table Goods in database >there are 1000 records, but on form Goods i can see only 100 records >without scrolling. Then delphi fetches only first 100 records and it >will fetch other 900 records only in case when i make client sorting or >scrolling in grid or something else. > >How can i do the same in ADO.NET ? I would image that it might be done with an open connection and cursors, and if this is the case it is not a scalable solution. In a disconnected design like ADO.NET you need to think about data like the network cord could be pulled from the machine at any minute. You design you collections, data tables, or whatever to pull all the information that you need in one shot, and then close the connection. I keep stressing generic collections because it solves a lot of problems in the dataset world. The only reason I would use a dataset is if I need to have a foreign key relationship and didn't want to write the classes to do it in a collection. All of the questions you have asked lead to a more involved design than a basic dataset. Most important is that you can enforce business rules on a very granular level, validate data, and raise meaningful events to the user/application. With just a little more work you can add design time support with and drag drop data binding. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Firebird-net-provider mailing list Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
