|
Paul Watson wrote:
Do you agree, disagree?
I can see this becoming an issue when this design forces you to load all of the records when you only needed a subset. In my design I abstracted even further to address other problems, but it looks like it could solve this 'problem*' as well.
I have: AdvertiserCollection -> Advertiser -> AdCollection -> Ad
None of these classes know anything about databases; I have separate classes responsible for that, and they take into account whether all of the records are needed or only a subset.
*This only becomes a problem when you are fetching all of the rows when you don't need to. If your current code doesn't do this, then there isn't a problem now but there could be one in the future when you forget about this and wonder why it performs badly.
James
Sig code stolen from David Wulff
|
|
|
|
|
James T. Johnson wrote:
None of these classes know anything about databases; I have separate classes responsible for that, and they take into account whether all of the records are needed or only a subset.
Fully, I certainly have not made it so that each time I need a list of Ads from a certain Advertiser that each Ad constructor opens a DB connection and pulls down just it's own details. But I have not gone as far as to abstract the database bit out of the class, mainly for time sake as Mr. Client paid for an el-cheapo-quick-fix version  (you should have seen the arguements I had with the client trying to get the database re-designed. whole portions of the database have no relations, no primary keys, no identity seeds and even allow NULL values which just causes endless problems. But then the other half does, so it is just a nightmare.)
Anyway, thanks again for the info 
|
|
|
|
|
Paul Watson wrote:
I have not gone as far as to abstract the database bit out of the class
I did it mainly because I'm still up in the air over if I'm going to use Access or MSDE on the client's computer. This approach keeps most of the code the same, changing just the *DB classes.
It also bridges on whether I can get him to upgrade his last crappy PC to a new Win2K box. I don't think I want MSDE running on a system with only 64MB of RAM 
James
Sig code stolen from David Wulff
|
|
|
|
|
You're in trouble: this kind of code, although OOP-friendly and very elegant, always lead to bad performance, sooner or later.
Unfortunately, the COM+ way of doing things and having stateless components wich usually only return the needed data asked is the way to go if you have performance and scalability concerns, despite its ugliness.
The collection-style data access layer also puts you in trouble when you need your data in different ways. The way you are designing you collection classes do not reflect properly a relational database and can leave you in really bad water when in the future you need even the simplest reports or calculations.
If you decide going this way, it’s better choosing a object oriented database instead of a relational database, e.g. Caché, which allows you to store things this way, takes care of the issues you noticed and lets you query it in a flexible way.
Q261186 - Computer Randomly Plays Classical Music
|
|
|
|
|
Daniel Turini wrote:
although OOP-friendly and very elegant
Damn you had me going with that... and then... 
So if this way is elegant and what not but bad for performance and scalability what is the point? Why have the collection option at all? Or am I using it in a bad way?
Daniel Turini wrote:
Unfortunately, the COM+ way of doing things and having stateless components wich usually only return the needed data asked is the way to go
Got any examples/samples of this way? Would be interested to see, ta.
BTW with James' help it seems data is only pulled when needed, and not just when the top level collection is instantiated, thankfully
|
|
|
|
|
|
About the database. Is it possible to create a view from these mangled tables, adding the required constraints and indexing, etc. through the view. You would then be able to properly insert new records with newer applications, as well as beeing able to use DataSets. If its not possible to create views with the current DBMS, it might be worthwhile to convince your client to upgrade to MS SQL Server, and just import the data, then create the views.
It just seems like your going through a ton of work just to represent/provide data in the way you want. And the way your going about it, no offense meant, looks like it could possibly create more work later on, (i.e. in the future). (I know, clients NEVER care about the future, and get cranky when you mention it.   )
Anyway, just some thoughts after reading the thread.
|
|
|
|
|
Jon Rista wrote:
your client to upgrade to MS SQL Server
We are using MS SQL server and I am making use of views and stored procedures. First off views are a touch limited and I am no pro at stored procedures (where is the intellisense!  .)
For instance part of pulling the product out of the database involves checking the users delivery country, checking various special offers and special rules and then calculating the price. It gets complicated because each order can contain multiple delivery addresses (e.g. you buy three items, two for yourself and one for a friend) and each item is priced according to weight, type and time of year. There is also gift wrapping, gift tags and multiple VAT rules (including the fact that some products are exempt from VAT in certain countries due to their type.)
So basically there is a lot of "business logic" going on which is all calculated from the base data.
Now I thought that was the whole point of classes and a data abstraction layer. i.e. The database persists data. Store procedures and views provide the data (and to some extent stored procedures do business logic) to the classes and then the classes do various calculations and offer up that data in a nice usable way for the programmer to implement into a nice UI.
You mention DataSets (and so did Paul) but how is that going to improve things? Surely I am still going to have to encapsulate all the business logic somewhere and still then provide the DataSet data up for use to the front-end (or do DataSets allow for "complex" calculations to take place "inside" them in some way?)
Anyway thanks for the interest
|
|
|
|
|
DataSets are really just an in-memory cache of your database, or a part of it. And they don't nessesarily have to have a GUI. They can be created in conjunction with a schema, allowing for all the relationships and whatnot to be properly maintained in memory. You could load your data from the database into a dataset, use that as your database while doing your calculations, etc, and then persist that back to the database server when your done. It can improve performance and help keep things properly restricted.
|
|
|
|
|
create a workthread in c# ,and use Thread.Sleep(100000) in it.and when the main app exited ,the thread is still working!!!!
call the thread.Abort() and thread.join(0).It seemed useless.
what is the problem???
Is that a framework's bug??? 
lost my way
|
|
|
|
|
Thread.Abort does work but it is documented that it won't happen immediately, it finishes whatever it's doing first. I'm guessing but I think it's just waiting for your Sleep to finish.
Paul
Why don't you take a good look at yourself and describe what you see - Led Zeppelin, Misty Mountain Hop
|
|
|
|
|
Paul Riley wrote:
it finishes whatever it's doing first.
Correct, more specifically it will run until it gets to a safe place to throw the exception. In this case it waits until it is done running unmanaged code before throwing the exception (Thread.Sleep is actually a P/Invoke'd call to the OS, judging by ildasm output).
James
Sig code stolen from David Wulff
|
|
|
|
|
not exactly,thread.Abort() never worked.
you can try this:
workthread()
{
while(true)
{
Console.WriteLine("thread will sleep");
System.Threading.Thread.Sleep(50000);
Console.WriteLine("thread is awake");
}
}
and after you called thread.Abort() and exit the application,the thread never stop.
Is that to say,abort() will never find a safe place to throw a exception????
lost my way
|
|
|
|
|
This code works for me
save as ThreadAbort.cs, compile with csc /out:ThreadAbort.exe /target:exe ThreadAbort.cs
Even better, if you have VS.NET you can watch the output window and it will tell you when the thread has exited.
using System;
using System.Threading;
namespace ThreadAbort
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
Thread f = new Thread(new ThreadStart(Run));
f.Start();
Thread.Sleep(1500);
f.Abort();
Console.ReadLine();
}
static void Run()
{
while(true)
{
Console.WriteLine("thread will sleep");
System.Threading.Thread.Sleep(2000);
Console.WriteLine("thread is awake");
}
}
}
}
James
Sig code stolen from David Wulff
|
|
|
|
|
yes it can abort a sleep thread,but...............?
maybe my code have some logical error.
thanks whatever!!!!!!!!!
lost my way
|
|
|
|
|
Thread.Abort() does work...its just fickle. Its also pretty much required that you catch the ThreadAbortException that Thread.Abort() throws. Its also a good idea to call Thread.Join() immediately after your call to Thread.Abort(). Thread.Join() will cause the calling thread to wait indefinitely until the child thread terminates. If you do not put Thread.Join() in, the application can exit before the child thread does, in which case the child thread will most likely never exit. The reason for this is the application repeatedly fires off the ThreadAbortException until its actully caught and dealt with. When the application exits, the ThreadAbortException can no longer be thrown, resulting in a dead thread that won't go away. I tried this, and it seemed to work fine (I tried 5 times, properly exited every time):
using System;
using System.Threading;
namespace TestThreadAbort
{
class TheTest
{
[STAThread]
static void Main(string[] args)
{
Console.WriteLine("[M] Starting worker thread.");
Thread t = new Thread(new ThreadStart(WorkerThread));
t.Start();
Thread.Sleep(170000);
Console.WriteLine("[M] Killing WorkerThread...");
t.Abort();
Console.WriteLine("[M] Main thread waiting...");
t.Join();
Console.WriteLine("[M] Goodbye.");
}
private static void WorkerThread()
{
try
{
while (true)
{
Console.WriteLine("[W] WorkerThread saying hello.");
Thread.Sleep(50000);
}
}
catch (ThreadAbortException)
{
Console.WriteLine("[W] WorkerThread saying bye-bye.");
}
}
}
}
|
|
|
|
|
Jon Rista wrote:
The reason for this is the application repeatedly fires off the ThreadAbortException until its actully caught and dealt with.
On the contrary, you cannot fully catch the ThreadAbortException. Once execution has exited the catch block, the CLR will continue to rethrow the exception until: 1) Thread.ResetAbort is called which cancels the request to destroy the thread or 2) All of the finally blocks have exited, allowing the thread to die.
James
Sig code stolen from David Wulff
|
|
|
|
|
When I made new windows service solutions, it's notice that "VC not found or has not registered". Please help me how can I solve this problem.
My .NET is Enterprise Architect. Please mail me
Thanks
Duc Phuoc
Email : il9u@yahoo.com
|
|
|
|
|
hi,
i have a problem with modeless forms...
When i click a button and execute the code below it works...
OnClickButton()
{
..
FormX MyForm=new FormX();
MyForm.Show(); // it creates a modeless form as expected!..
..
}
but when i call these two lines of code in another function such as a CallBack function like OnReceiveAsync() in my Client program or in a timer delegate function like Timer_Elapsed() it doesn't works...
it tries to create MyForm but it does not properly appears and it locks the whole program..
is it a bug? or should i do something else for Modeless forms & dialogs..
Please try it your self and see what happens..
Modal forms (MyForm.ShowDialog();)
works properly everywhere whether called by clicking on buttons or
calling via another function
but why modeless are not?..
Thanks for ur help...
just listening to you...
|
|
|
|
|
|
Thanks Daniel..,
it works now with ur help,
here what i did...
maybe it helps for others...
Whisper.ShowMessage(); // i put this line it instead of two commented out
lines below;
//Whisper NowWhisper=new Whisper();
//NowWhisper.Show();
protected static Whisper NowWhispering;
public static void ShowMessage()
{
NowWhispering=new Whisper();
Thread t=new Thread(new ThreadStart(NowWhispering.MyShow));
t.Start();
}
protected void MyShow()
{
Show();
while(NowWhispering!=null)
Application.DoEvents(); // i think this line protects locking..!
}
just listening to you...
|
|
|
|
|
can anyone help me out with the coding conventions that are recommended for .NET users.....as i would be recommended by micorsoft!
and a little bit of detail would be appreciated specially about naming controls...for example a textbox!
thanks!
|
|
|
|
|
rule number one : no more than one exception per line.
How low can you go ?
(enculage MS)
|
|
|
|
|
|
i have read all that...its inconclusive...
as i said i want concrete information what is the best way to name a control....there is no such description of controls on the msdn article....can you help me out with something else?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
