|
MSMQ is still very much in active use. It's just not talked about as much, and is generally hidden behind abstractions such as WCF.
|
|
|
|
|
I'll preface this by saying that I'm not exactly a DB programmer, though I've been doing more and more of it lately.
Say you have a typical database with Products, Customers, and Orders tables. The Orders table is an associative table with foreign keys to Products and Customers. Standard fare. You have a UI front end for the database with views for viewing many records and views for viewing/creating a single record.
A customer calls to place an order, so the operator fires up the Create Order form to enter the data. On the form are the controls for entering the data, like textboxes, checkboxes, etc. Once the order info has been entered, the operator hits the Submit button, and the order is added to the Orders table.
However, the Orders table is an associative table, so the info for entering the customer ID as well as the product ID needs to be correct, i.e. the values entered into those fields need to correspond to an existing customer and product respectively.
My question is what are some ways in which this can be implemented in the UI? One could use list boxes for the customer and product so that the operator can easily choose values from those tables to enter in to the order. However, this approach doesn't scale well. There could be thousands of products and customers to choose from. Putting them all into list boxes isn't really going to work. Maybe instead some type of table view that can popup to let the operator choose from it?
How is this usually handled in DB applications with a UI front end?
|
|
|
|
|
|
You are right, drop-downs and lists don't work so well when the list gets longer.
In the past I have worked on systems that give the user some sort of search facility (a button they can click that pops up a screen to let them search with wildcards, that sort of thing). That works for pretty much any size of data set.
More recently, auto-complete or auto-suggest have become popular (the user starts to type and the system suggests matching values that gets refined into a shorter list as the user types). That works quite well for larger data sets than you might think.
Or, you can subset the information based on something else they have filled in (for example, entering a postcode or zip code brings up a list of street names and house numbers that match, which is a manageable list size once you have even a partial postcode).
|
|
|
|
|
I like to use auto-complete but you need to consider a few CRUD issues like when new customers are added etc. In a multi-user environment with many thousands of customers this may not be an option, in which case validating the entry is a better solution. Typically the UI will ask the model if the customer exists. If not the UI needs to manage the situation and ask the user if it is a new customer or provide a drop down list of possible matches i.e. Customer name "Acme" may return "Acme Sydney", "Acme Paris", "Acme London". In this scenario you can still use auto-complete just don't populate until validation returns a mismatch.
Architecture is extensible, code is minimal.
|
|
|
|
|
Leslie Sanford wrote: A customer calls to place an order, so the operator fires up the Create Order form to enter the data. On the form are the controls for entering the data, like textboxes, checkboxes, etc. Once the order info has been entered, the operator hits the Submit button, and the order is added to the Orders table.
However, the Orders table is an associative table, so the info for entering the customer ID as well as the product ID needs to be correct, i.e. the values entered into those fields need to correspond to an existing customer and product respectively.
Nice workflow. I'm imagining an MDI-app where the name of the current logged in user can be found somewhere near the edges. It's a three-step proces, so feels like a wizard. I'd generate the Sql, put it in a list, and on "Finish" execute all in a transaction, or roll back on error.
Page 1, customerselection page;
Input Textbox 1 - typing a partial name should update the grid below;
Input Textbox 2 - typing should update the grid based on soundex;
DataGridView - containing all the data relevant there, not looking much like a grid, and with full-row selection.
Next, Product registration
The exact same pattern again
Next, Order
The exact same pattern
Finnish
START TRANSACTION
COMMIT TRANSACTION
I are Troll 
|
|
|
|
|
If you are looking for a solution that can scale well you've to think about severals forms.
Following your example, if in UI you have to select a Customer or a Product, the main form (the New Order one) holds something like a textbox to hold a code that will come from another search form which performs the search between the target needed.
So, in that form you can put a set of controls and code to refine and help the search and when one is selected the "target" code is passed to the UI caller. Those search forms could be implemented in several ways (web services, dlls, etc)
This solution is analog to the windows common dialog everybody uses to select a file.
If you want to go a step forward you can build a wrapper service to ask for every searcheable entity in your database asking dynamically for the db schemas to use related fields or indexes that already exists and compose a dynamic UI for the search.
|
|
|
|
|
You could make a thing in google stile, in a textbox type a char and only products beginning with that char will be displayed, for example in a combo. Then typing one more or more char and so on, finally select the product by name by id as you like 
Piccadilly Yum Yum
|
|
|
|
|
Hi All,
Not sure where the best place to post this on the forums really.
I've been tasked with making a decision about buying a POP3 component. Anyone have any experiece with using commercial POP3 components and can share user experiences. I'm mainly looking for components with solid attachment(s) handling capabilities.
Any input would be great.
Cheers,
|
|
|
|
|
I'm mainly looking for components with solid attachment(s) handling capabilities.
As opposed to liquid attachment(s) handling capabilities ?
Just joking
|
|
|
|
|
haha ... I only deal with s*** ... 
|
|
|
|
|
|
Since you seem to be looking for a .NET component, you might have better response posting this on one of the .NET/C# forums.
|
|
|
|
|
|
Thanks for sharing
|
|
|
|
|
This is a general and basic question about object oriented design. I've been programming for many years, but just recently I've started realizing many of my old ways of doing stuff is flawed or just plain wrong in terms of good OO design.
Simple case: You have class A and class B which have some overlapping properties. You want a method that copies or converts the common properties from class A to class B. Where does the method go?
1) Class A as a B GetAsB() ?
2) Class B as a constructor B(A input)?
3) Class B as a method void FillWithDataFrom(A input)?
4) Class C as a static method B ConvertAtoB(A source)?
Thinking of SOLID principles and testability I have a hunch that 4) is the best answer, but I'd like to hear some rationale. Maybe there isn't a definite answer?
|
|
|
|
|
I would personally use a static method called "Clone",temp = YourClass.Clone();
Hope it helped... 
|
|
|
|
|
Well it's not really a clone. They have SOME overlapping properties, but they are different classes.
A concrete example similar to what triggered my question: I have a MVC-project where the model class is class A and the ViewModel is class B:
class Model
{
string Name;
string Timestamp;
string Token;
}
class ViewModel
{
string Name;
DateTime Timestamp;
}
I am not interested in showing the Token, and the Timestamp has to be converted to a DateTime class, which then is presented better by the .NET framwork's DateTime.ToString().
Where do I do the conversion? Now if I put the code in either Model or ViewModel, I will introduce a dependecy between the Model and the ViewModel. If my Model-class changes, the ViewModel must change. So my question is really if that is always a bad thing (option 1,2 or 3 from the original post). Don't they have an intrinsic dependency anyway?
|
|
|
|
|
In your concrete example, I would let the ViewModel have a reference to the Model.
In this way, you hint that the ViewModel is in sync with the Model and you don't have to duplicate data.
If you consider DateTime strictly as a presentation data type, the data model should NOT know about it. Hence, you need to put DataTime operations outside the data model e.g. in ViewModel or a data type converter.
To illustrate this cut, imagine that you MUST put your model code into 1 library and MUST put view model code into another library. Furthermore, the view model MUST know the data model, but the data model SHOULD NOT know the view model.
This is the classic MVC pattern: http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller[^]
With all that background info, either or both of the following conversion services would work:
<br />
Model model = new Model();<br />
model.Timestamp = "0227011";<br />
DateTime timestamp = model.Timestamp;
<br />
ViewModel viewModel = ViewModel(model);<br />
DateTime timestamp = viewModel.Timestamp;
Hope it makes some sense!
|
|
|
|
|
Thank you, this makes sense yes. Usually one don't have to worry about dependencies going downward in the project hierarchy, I guess. It's all this new IoC-trend that just got me rethinking a lot of the old paradigms.
Another thing - slightly related: What do you (or anyone else who care to answer) think about referencing the Name property from the Model in the ViewModel directly, instead of copying it? Would this breach some kind of archictecture/dependency principle?
So...:
class ViewModel
{
public Model ModelInstance
public DateTime Timestamp;
}
This way the View accesses the Name property directly on the model through the ViewModel. If ASP.NET: <¤= ViewModelInstance.ModelInstance.Name %>
I read an article by Rockford Lhotka[^], creator of the CSLA framework, that encourages such an architecture. I'm not convinced everybody agrees, but I kind of like it. It minimizes property duplication. See in particular the chapter "ViewModel as Action Repository".
|
|
|
|
|
Your most welcome.
Yes, I am all for the approach with a Model reference in the ViewModel.
Thx for the link. I like the discussion. The MVVM architecture is however not my best friend (though very popular these days).
I prefer MVC with the a twist, where the C stands for Command (think a simple Controller that performs a specific Algorithm).
The Command Pattern is classic, but I have not seen much recent discussion about it, but here is a link with a little discussion: http://c2.com/cgi/wiki?CommandObject[^]
Since a Command can be both a Controller and Algorithm, you have a single class with the full responsibility (and all the code) of getting a specific task done.
When you got a bug, you know where to look. You automatically re-use code, since you just run the existing commands or combine them into composite commands e.g. sequences or parallels. When you think about it, most tasks can be specified as a command or composite commands: request, sleep, set, create, delete, save, undo, shutdown, etc. Execution of commands is a topic on its own, just like execution of CPU/VM instructions, fibers, threads, jobs, etc.
In the MVC, I let M be the model, let the V be the View that listen on the model and let the C be the commands that changes the model. Both the model and view may issue commands. If you don't like the Observer pattern, the view can be modified by commands that are called from model commands.
Just like Rockfor Lhotka suggests in "ViewModel as Action Repository", I create MVC layers when its makes sense e.g. when in need of faster response and I create a MVC subsystem when it makes sense in terms of a "black box" e.g. an application, a view or a dialog.
I hope above triggered some thoughts.
|
|
|
|
|
Nilzor wrote: You have class A and class B which have some overlapping properties.
That's one way to describe it. What happens when I say that the overlapping properties are class BaseAB, and that both class A and Class B inherit that?
..or call the shared properties Class SharedStuff and nest it as a property in both Class A and Class B.
Nilzor wrote: Maybe there isn't a definite answer?
There's never a definite answer
I are Troll
|
|
|
|
|
Inheritance wasn't even in my mind. Although it wouldn't be the best choice in the specific case i mentioned in my second post, it definitely shows there are many ways to solve this - it depends on the case. Thanks for your and Shlasko's input!
|
|
|
|
|
I usually opt for something similar to #4, but put the static method inside B so it can work like a factory constructor...
B newObject = B.FromA(original);
But since you mentioned in your other reply that these are two different layers, well... Depends on:
1) How much interaction you're allowing between your layers
2) Which layer is dependent, if any (If A depends on B, then A can have code that converts to/from B)
I work mostly in WPF, which is best done with MVVM... I tend to put translation-type logic in the ViewModel, since that's dependent on the data model (But the data model knows nothing about the viewmodel).
|
|
|
|
|
Option 5. Create an interface that encapsulates the properties, and have both classes implement the interface. Use that as the basis of filling the properties.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
