Design and Architecture

Doesn't matter - I figured it out If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done - Peter Ustinov

netJP12L wrote: Moreover, what about when we type a word does slide sorter recreate a thumnail. Possibly, and maybe probably. Deja View - the feeling that you've seen this post before. My blog | My articles

Thanks!! it should be just a typo! :-D Fakher Halim

If you want to generate the invoice number as a natural key in code, I might suggest a singleton that would be responsible for generating it (possibly date + sequence based), however, you need to consider other factors that would get messy by storing the "Invoice Number" as a single column. For instance, if the system started generating invoices today (080705-001) and shuts down unexpectedly, say at 10am, when it starts back up, it would have to reparse the invoice numbers (like '080705-%' to get the last sequence number...obviously, this would be far from ideal. Also, by storing the invoice number in the database, you are now "stuck" with the formating decision you made at design time. If you start generating more that 1000 invoices today, you will have duplicate invoice numbers (another bad situation). Many systems push back the ultimate problem by adding customer id to the invoice number... Anyway, if you store the invoice date separate from the sequence number, you can retrieve the last sequence number quicker, you are not stuck with a format problem, and you can move the format issue to your business layer if you do have issues.

Pete O'Hanlon wrote: In most cases, where the even has been raised to perform the update, you will have supplied the instance of the object that raised the event in the sender. Each observer could compare it with its own instance to see if it is the current instance and ignore it if necessary. I thought about this approach, but settled on the one used by MFC's Document/View architecture, e.g. UpdateAllViews. I think your suggestion may be more robust in that it gives an observer the option to handle the event even if it is the one responsible for raising it. However, MFC's approach is slightly simpler, so I went with it instead. BTW, there aren't many places where this is addressed in .NET, is there? It's been a few months since I've programmed in .NET, but I seen to recall that most/all "event handlers" are private or protected. So it's not possible for an outside observer to raise an event directly by calling an event handler on a subject, passing itself as a sender. What I remember doing when I was concerned about redundant notifications was using a boolean flag inside the observer indicating when it should ignore an event. This always seemed kludgey to me.

variantseeker wrote: We are writing a server app for Linux in C++. Did you check out the W3C and Apache libraries? led mike

I am not aware of any books. I don't know if this subject is on c2.com but there are certainly some that might qualify as off the well-beaten path. led mike

a boy has a hand : composition, there is no hand without the boy. an appartement has a building : composition ---------------- in contrast : a car has a driver: aggregration

I'd be inclined to use something that does caching properly. Otherwise you'll end up with annoying bugs, like products being added, and your dropdown lists won't show the new products until the worker process is recycled. If your pages are going slow because of many database round trips, then consider using asynchronous pages. Mark Churchill Director Dunn & Churchill Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.

God Bless u Mark Churchill. U are damn right and u have just saved someone from a burning station! :^) Thanks a lot and more thanks for the information shared. :-D Now, to have my major worry settled, I just need to know how to connect to the POS machine in the fuel pump from a C# application and get the litre or cash values so that I can at least, record the sales of fuel for a prepay scenario. I have heard of WEPOS and POS for .NET but I don't know if that will do. I will appreciate any assistance or walk around rendered. Just to add, secondly(minorly), I've observed something during prepay sale which i want to bring to your notice. While fuel is pumped into the vehicle, if the user holds down the inner holder of the hose nozzle at intervals, the volume of fuel released after pump or sold will be reduced! Suprisingly, I've confirmed this with sale measurements to fuel galloons. Perhaps, nozzle manufacturers might be able to build hose nozzle models that can't interrupt the volume to be dispensed. What do you think? Anyway, thats by the way, my concern right now is how to solve my major worry as stated above. Many more thanks in advance as I look forward to hearing from soon.

If its a proper, published interface API then future releases should be backwards compatible. There is no guarantee of course, but no respectable company would replace a function with another of the same name that did something totally different. For example, in version 1.1 fuuntion F1(int a,int b) returns a + b would never be replaced with funtion F1(int a,int b) that subtracts them, it just isn't done. That said, it should be standard practice to regression test whenever you are considering using a new version of any software. Hope this helps Bob Ashfield Consultants Ltd

Luc Pattyn wrote: I'm unanimous on this Why thank you Mrs Slocombe. Deja View - the feeling that you've seen this post before. My blog | My articles

dabs wrote: would like some input from others regarding the best design for this Your not asking about design, you are asking about what feature should be implemented. That question needs to be asked for each project based on the project definition. An admin deleting threads and all it child replies is not at all equivalent to someone deleting text in a word processor. For this reason I don't believe the Undo is a good fit. A recycle bin where it must be manually deleted or perhaps expired but until then can be restored sounds like a much better use model for an Administrator and that problem domain. led mike

Noctris wrote: are there gotcha's in protocol design (for instance i found out that having an parameter to let the client detect when the command is done is an abolute must).? Not sure what that means. Noctris wrote: It's my first Client/Server application and I feel like i am in the dark. Not unusual, it's a large subject. Noctris wrote: I've found very little on designing a protocol Yeah I don't remember ever seeing anything like that. Try looking at existing protocols rather than looking for something that teaches protocols. I suggest you start with some simple application level protocols like HTTP/FTP/POP3 of course... Noctris wrote: what i need (basic question/response and synchronizing data, which i currently do using xml) That sounds like SOAP so you may not need to create your own protocol. It's difficult to say for sure with the limited information you provided. led mike

I tend to do modelling and implemention top-down. Okay, I tend to implementation a bit randomly, depending on how much research is necessary. Though, in general I start by designing the forms, then continue with the functionality necessary to fill them and finally get the background stuff the user doesn't notice. When I write code I always keep in mind, what it is supposed to accomplish, not the details at the bottom but ultimately the results on top. John C wrote: For example let's say I have a large project with hundreds of business objects, I would create all the objects first without any real code implementation, look it over think about the design, make changes as necessary, try to get it as quickly as possible to the point where I can roughly make a real interface to try out the workflow, then go in and fill in all the CRUD methods (create, read, update, delete), then go back in and add business rules or further refinements. I tend to do the same, in order to set the basic structure for the application.

About the same for me. Though, sometimes I stumble upon functionality where I quickly see it would be better to outsource it into another method, even if it only gets used a single time. I tend to look through any long methods I wrote to check if there isn't anything I can outsource into helper methods.

In theory I'd say anything that has a central function and doesn't use instance specific variables should be static. In practice, however, I usually go straight for instance implementation because you never know when you need to implement functionality which you can only access from an instance. It's a pain to change all the previously written code from static to instance. :sigh: I had that problem several times already, for example I recently made a connection class and wanted to make it static because I wouldn't need several instances of it. However, after implementing half the code I had to use classes/methods that could called from an instance so I had to change a lot of stuff.

I don't find any question in your post related to your subject line. You seem very confused about pretty much everything. I suggest that an internet forum is the wrong format for solving your problems. You need some good books or something. led mike

Uses case fundamentally has two kinds: business use case & system use case. Both have same way of presentation and almost same templates. If you have wrote use cases more towards to defines yours system or in other words interaction between different systems or interaction with system and human then they are more towards system use case. (e.g presenting available menus and their interaction). Business use cases are more towards to define business (e.g presenting available menu and their broad view of features) You should take another try to search material into web, lots of material available Akash

Class A only needs to have a method AddToList. I am visualizing from example that List is going to contain only pointer of Class A. Then base class object can point derived class object so basically this method not need to make virtual. Even though if list is going to have copy of object then need to implement copy constructor & assignment operator in each derived class to make appropriate copy. But from my point of view class responsibilities should not be mixed up it should be some controller class responsibility to collect object in list rather then Class A itself. So writing a separate method in any other class is better from design-wise. Or make a another class derived by CList and create a method e.g say: "CollectDataInList(A *a)" or have this method in class which is containing CList object. Akash