|
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.
|
|
|
|
|
just to clarify what you are asking,
Class A has properties X and Y
Class B has properties Y and Z
given
an instance of class A such that X = i and Y = j
an instance of class B such that Y = k and Z = l
you would like to achieve a modification to the state of class A such that X = i and Y = k
is that correct?
1. would not achieve this, it could only result in an instance of class A where Y = k and X = default(x)
2. likewise this would not be able to set the X property
3. This could achieve the result you are after, it would copy values for common properties from the argument instance to the instance of the class on which the method is hosted
4. as with 1 and 2 this would not be able to populate the X property
so, if the initial assumptions of your question are correct, i would go with option 3 
either that or I've misunderstood completely and have resorted to flinging answers at a non-existent hypothetical question, sadly that wouldn't be the least productive thing I've done today....
|
|
|
|
|
either that or I've misunderstood completely and have resorted to flinging answers at a non-existent hypothetical question, sadly that wouldn't be the least productive thing I've done today....
At least this made me laugh - I'm sorry but your initial assumptions is wrong But who knows- maybe some guy in Taiwan or Botswana Google's the question you answered, and it will come to use after all!
I do realize my question was a bit unclear. This is the initial state I was thinking of:
an instance of class A such that X = i and Y = j
There is no class B - I want to create a NEW class B, with the values of the common properties from A set, and the other default. So if class B has property Y and Z, whatever method we chose, the result should be a class B with Y = j and Z = (default)
|
|
|
|
|
In that case i feel it depends on the nature of the class
The constructor approach should be used if:
- Class A is logically a component of class B (e.g. A = Engine, B = car), although in this case i would prefer an instance of class A within the state of class B rather than copies of its state values being placed into the state values of class B
- The information in class A is (in part) mandatory for the creation of class B
The instance method approach should be used if:
- The logical functionality of the entity represented by class B is such that it would be expected to replace its state with that of class A (e.g. A = location, B = car, B.DriveTo(A) sets common 'lat/long' properties)
The static method should be used in other cases
Thats my view at least 
|
|
|
|
|
Would somebody care to comment on the difference between generalization, abstraction, and encapsulation?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
