سوال: مهم : برای کل پروژه از یک Typed Dataset استفاده بشه بهتره یا نه؟ [بایگانی]

vb_nima

چهارشنبه 12 اسفند 1388, 03:45 صبح

با سلام
من تصمیم گرفتم در پروژه ای از Typed DataSet استفاده کنم. (پروژه از نوع نرم افزار کاربردی تحت وب است نه وب سایت)
حالا سوالم اینه. فرض کنید من 30 تا Table اصلی تو بانک دارم. حالا به پروژه فقط یک Typed DataSet اضافه کنم و در همون برای همه Table ها TableAdapter بسازم اصولی تر و بهتره یا اینکه برای هر Table یک Typed DataSet جدا بسازم.
مخصوصا از نظر سرعت اجرای نرم افزار فرقی میکنه یا نه.

سلام دوست عزيز.
راستش برام خيلي جالب. با توجه به سوال قبليتون و اين سوالتون به اين نتيجه رسيدم شما هم يه جورايي مثل من فكر مي كنيد. آخه شما هم به همون سوالهايي كه در روند پياده سازي پروژه ام ميرسيدم ميرسين. (آخه من يكم گيرم. به همه چي گير ميدم ميخوام همه چي استاندارد باشه و يكار اشتباه انجام ندم).
منم به اين سوال شما رسيدم و توي يك آموزش اون طور كه خاطرم هست ديدم از يك typed dataset استفاده كرده منم قانع شدم و همين كارا كردم. البته چون شما گفته بوديد دليل فني ذكر كنيد يك سرچي زدم ببينم چي پيدا ميشه. يه قسمتي پيدا كردم ولي درست متوجه نشدم پاراگراف آخر چي گفته (كامل نگرفتم). اگر از دوستان كسي پاراگراف آخر را كامل متوجه شد برام منم بگه:
پاراگراف اول كه همون سوالتون را تشريح كرده.
پاراگراف دوم منظورش اين كه :" اون سازندگاني (توسعه دهندگان) كه براي هر table از يك typed dataset‌ استفاده ميكنند مي گند كه اين كار باعث ميشه واسه هر موجوديت حافظه كمتري گرفته بشه و در نتيجه زمان بارگذاري (Load) كمتر بشه." در ادامه گفته :‌"ولي اين نگرش يكي از مزاياي اصلي typed Dataset كه مربوط به relationships بين جداول هست را نفي يا خنثي ميكند." يعني زماني كه از يك typed Dataset استفاده ميشه از ارتباط بين جداول (relationships) ميشه استفاده كرد.
پاراگراف شوم هم ميگه كه :چطور از typed Dataset‌ استفاده كنيم به صورتي كه هم بشه از روابط بين جداول استفاده كرد و هم زمان بارگذاري را كم كرد؟ بقيه را ديگه درست متوجه نشدم.

How many typed DataSets?
Determining the number of typed DataSets required is one of the first stumbling blocks that designers encounter when using typed DataSets in their applications. For example, if you’re trying to represent a real-world order entry system, do you create one typed DataSet each for customers, orders, invoices, order line items, invoice line items, and products? Or, do you create a single typed DataSet that includes all of these database entities and use relationships in the typed DataSet to tie them together?

Developers who make the argument for creating individual business entities for each database entity defend it by saying that this uses as little memory as possible for the entity and minimizes load times when building the business entity. But this approach negates one of the key advantages of the typed DataSet (i.e., verifying referential integrity between the tables at the highest level of the application).

So how do you get the advantages of using relationships to verify referential integrity while minimizing load times and memory utilization? You create a single typed DataSet and then populate only the portions of the DataSet necessary for the operations you’re performing. In general, you’ll load the DataSet from left to right. For example, if you want to view the Orders and Order Line Items for a single customer and avoid referential integrity errors when loading the typed DataSet, you’ll put a single record in the Customers table, load all of the orders and line items in the Orders and Order Line Items tables, and load into the Product table the products that appear in any of the line items. However, if you just want a list of customers, you can load the Customers table but not load any of the other tables.
منبع: http://articles.techrepublic.com.com/5100-10878_11-5031979.html

پيشنهاد خودم: از چندين typed Dataset‌ استفاده كن ولي براي هر table‌ از يكي استفاده نكن بلكه جدولهايي كه از لحاظ منطقي باهم ارتباط دارند يا روابطي مثل "يك به چند" با همديگر دارند را داخل يك typed Dataset‌ بگذار.
اميدوارم مفيد بوده باشه.