|
dojohansen wrote: AS IF I have uttered anything even remotely suggesting that one should not use unit tests.
I assumed you were DELIBERATELY misunderstanding but I am beginning to doubt if you can control it.
No, but I did lose the thread as it has been a long one so, yes, I was wrong, you are correct, you never suggested that, my mistake. We were basically talking about two different things in regards to unit tests and it seems we might actually have similar views on both of them. Therefore it is at least partly my fault, if not completely, that we ended up in a confrontation rather than a discussion.
dojohansen wrote: Have a nice weekend.
thanks, same to you.
led mike
|
|
|
|
|
Where can I find some online guidance regarding the creating the ultimate user experience, with regards to exception handling? Jeff Atwood's catch-all solution[^] is very attractive, but I'd like to read up on the finer points, in a design aspect, of handling those unpleasant little situations where the user gets told something bad.
|
|
|
|
|
My [self-serving] opinion is: just tell the users that a problem occurred but that tech support (or whoever) has already been notified. Then when you get the notification, call the user.
there is no point in telling the user that "someclass encountered a null blah blah exception in method whatever(arg,arg,arg,arg) at line 42075 of module someclass.cs": in general they have no context to understand what it means, they cannot do anything about it, and frankly it scares quite a few of them.
telling them instead "oops, my bad" and then following up in a timely fashion [i.e. before they forget what they were doing] is far better - it makes you look like you're on top of things, and it gives the user a warm fuzzy about the application and your commitment to supporting it
again, this is just my [self-serving] opinion. 
|
|
|
|
|
I'm looking for good books or online sources that describe techniques for using object composition. Specifically, I'm interested in the idea that you can have objects within objects, several layers deep and how this can be a beneficial approach to managing application complexity.
I'm already familiar with most of the books out there on OOP, e.g. Design Patterns, Refactoring, etc., so if you can recommend something that deals with this subject that's off the well-beaten path, I'd appreciate it.
|
|
|
|
|
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
|
|
|
|
|
I'm designing a group of tables where each table offers both natural keys, e.g. invoice number, or surrogate keys, e.g. InvoiceId or InvoiceGuid. The PK for each table is a domain independent integer identity column, and each table has an optional natural key field. <pre>
[Example Table] recordId int identity,
exampleId nvarchar(20)
</pre>
Where the 'example' prefix is specific to the Example table, and an invoice table will have an invoiceId natural key field. It strikes me that we are in an inheritance centric solution space, but that will have to wait for the Entity Framework. Are there any established patterns for going about maintaining both types of keys?
Last modified: 123hrs 24mins after originally posted --
|
|
|
|
|
Are you asking a question?
Mike Lasseter
|
|
|
|
|
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.
|
|
|
|
|
We are writing a server app for Linux in C++. In order to avoid reinventing the wheel we want to use some kind of library that already implements common architectural patterns and provides solutions to problems that arise during server development. The Java and C# community are well endowed in this regard. Is there anything similar available for C++??? We did find IBM's Reusable Server Kernel (RSK) but unfortunately that is meant solely for their VM systems. A similar truly cross-platform library would be just what we are looking for. Thanks in advance for your help.
|
|
|
|
|
variantseeker wrote: We are writing a server app for Linux in C++.
Did you check out the W3C and Apache libraries?
led mike
|
|
|
|
|
I posted a message to comp.object about this subject, but decided to post a modified version of the question here.
What I'm trying to grapple with is the cyclic nature of architectures like MVC that rely on the Observer pattern.
Say that you have a subject (or model in MVC terms) that has a set of observers attached to it. When the subject changes, it notifies its observers. Ok, good enough. But suppose that one of the observers is responsible for changing the subject. Being an observer it will receive a change notification from the subject after changing the subject. In turn, the observer may choose to update itself by querying the subject. However, this update is unnecessary as it was responsible for the change in the subject in the first place.
I was looking at MFC's Document/View architecture for inspiration. The CDocument class has an UpdateAllViews method. The method takes a CView object as a parameter. This object represents the view responsible for changing the document. The CDocument skips over it when updating its views so the specified view doesn't update itself unnecessarily. This approach requires that the View be the one responsible for triggering an update (maybe not in all cases, I'm not all that familiar with the Document/View architecture).
At any rate, this provides one way to break the cycle created by the Observer pattern when an observer can be responsible for changing its subject.
Thoughts?
|
|
|
|
|
Leslie Sanford wrote: Thoughts?
Yes this is a common problem. The solutions vary and discovering which one is best suited is likely dependent on specific aspects of each project.
See this article for example[^]
led mike
|
|
|
|
|
led mike wrote: Yes this is a common problem. The solutions vary and discovering which one is best suited is likely dependent on specific aspects of each project.
See this article for example[^]
Nice article! Thanks. I learned some new approaches.
However, what the article means by redundant notifications[^] isn't exactly what I described here. My concern is an observer receiving a notification when it is the one responsible for changing the subject. The Document/View's UpdateAllViews approach seems to be one way around this.
|
|
|
|
|
Leslie Sanford wrote: However, what the article means by redundant notifications[^] isn't exactly what I described here.
Yes that's what I meant by the solutions will vary and need to be specific to the aspects of any given project.
led mike
|
|
|
|
|
Perhaps try taking a look at how Datbinding works in .Net. It implements its updates exactly as you described.
This can be a PIA in some situations, especially if you require a field to be all caps and want to control it in your property like _someproperty = value.ToUpper(). In this case your ToUpper changes don't get pushed back out to the control.
Mike Lasseter
|
|
|
|
|
Could your observer not unsubscribe from the subject, make the change and then resubscribe once the change has been made?
Adam
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
I have something brewing in the back of my mind for sharing the tables that populate common drop-down lists, along the lines of a singleton 'list provider', or at worst, a shared DataSet with tables for lists, populated on demand. I'd just like to know if there are any other patterns for doing this.
Example, many of my forms have the same Product dropdown, so I'd like to factor out the information shared by each instance of the list, i.e. the stored proc name, or query, and the display and value field names.
|
|
|
|
|
Brady Kelly wrote: a shared DataSet with tables for lists, populated on demand.
What does populated on demand mean? Lazy Initialization?
Brady Kelly wrote: so I'd like to factor out the information shared by each instance of the list, i.e. the stored proc name, or query, and the display and value field names.
I don't understand, are you not using DataBinding? You can bind as many controls as you want to the same DataSource. I have no idea what you are trying to do. 
led mike
|
|
|
|
|
I'm trying to remove the 'how to knowledge' for populating value-text lists from the clients of those lists, as my e.g: I use a Product drop-down on several forms. I don't want to duplicate the code to populate the product list in each place I have a product drop-down.
|
|
|
|
|
Brady Kelly wrote: I don't want to duplicate the code
What code, you set the DataSource property etc.? If you want to go to the trouble of creating a custom control then you can use it on all your forms. Having the same drop down list on multiple forms sounds like poor UI design anyway. Oh wait, this is a Browser application isn't it? Never mind. 
led mike
|
|
|
|
|
I'm trying to move toward something like a 'list service', from which I can request a list by name, e.g. Product, and get a list of products suitable for a drop-down. This is for both browser and winforms applications. Then all I need to is set DataSource to my list, which is somewhat standardised, i.e. it always has a Value property and a Display property.
|
|
|
|
|
Well, you could always use a Dictionary for this - possibly stored in the Cache for you web site (and static for the winforms). The dictionary would be of type string and List, where you would retrieve the list based on it's name. It's not an elegant solution and just screams quick and dirty hack to me, but it should work.
|
|
|
|
|
I'll look at using the cache, but I don't think it would be too much of a performance hit to reload the lists for each initial page access. I prefer a stateless approach, and it's the means of loading the lists I'm trying to abstract away more than the actual storage and or lifetime of the lists.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
