|
Member 849873 wrote: I have been given access to a data feed, which provides me with live, real time data. I need to cache this data and do some processing on it, and I can only create one connection to this service - it will block any subsequent attempts from the same IP. Therefore directly connecting via a website is not going to be feasible.
Let me rephrase that; you have a feed with data, and you can get the feed once. What does the word "realtime" do here?
Member 849873 wrote: a back end service that retrieves the data
Once as you explained. Since it's a feed, there's no way to stay connected to that. Then what? Change your IP and fetch the feed with real-time data again?
Member 849873 wrote: As the data is real time - the ability to update the web page in real time would also be desirable.
You mean that CHANGES made by an employer in record A should also change that employee-info "straight away", even while the manager is looking at the webpage?
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
My advice is to have one part of your project worry about keeping the connection alive and putting that data into a database (on your side) as quickly as possible, then do any analysis against the data in your database, not on the way into the database.
|
|
|
|
|
My question is about CommonApplicationData folder, how to use it. In my setup program I have created "Application Data Folder" then sub folder [Manufacturer]\[ProductName] where I store my data files but my question is during the testing/debuging process where I store those files so my program can access them or do I have the change the path after I done all the testing?
|
|
|
|
|
Why can't you store the files in [CommonApplicationData]\[Manufacturer]\[ProductName] ?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hi,
I am trying to be fastidious about following enterprise application architecture best practices in my development and that includes using design patterns.
I have a new requirement to write a C# service using .NET 3.5 and what it does is, after a timer goes off, it runs various database queries to retrieve needed information and then writes out a text file to disk. The text file contains the data, but the file has to be formatted in accordance with a set protocol.
This is not client/server. This is an automated, faceless process implemented as a Windows Service.
Any tips or tricks on which VS tools/techniques and patterns in the VS2008 and .NET 3.5 world would be most useful for this type of requirement? I'm only asking because I am still relatively new to patterns.
Sincerely Yours,
Brian Hart
|
|
|
|
|
Store as an XML file, consider XML processing as you are dealing with multi-databases, don't worry about design pattern at this point, it should work fine
|
|
|
|
|
Brian C Hart wrote: I have a new requirement to write a C# service using .NET 3.5 and what it does
is, after a timer goes off, it runs various database queries to retrieve needed
information and then writes out a text file to disk. The text file contains the
data, but the file has to be formatted in accordance with a set protocol.
Pretty sure you can do that without C# at all.
Windows has a scheduler. Most databases provide output capability. So is there some other requirement?
|
|
|
|
|
I am in an old fashioned shop that has distributed a complex software system to manufacturers of packaging, some who haven't even upgraded from Win2000. So I have no choice but to do a C# service. So I am asking what is the best design pattern to use for a service? Will some one please just answer me that question. Boss is making me do it this way. I have no other choice.
Sincerely Yours,
Brian Hart
|
|
|
|
|
You might look at a translator pattern.
However your description isn't that complex so without additional requirements it is just a basic export process.
|
|
|
|
|
I'm starting a new WPF app. The app's visual layout is pretty simple[^].
I have done apps like this before, but I'd like to revisit the way I do this.
Basically, the main content area contains a Content Presenter that is bound to a property called MainContent in the MainWindowViewModel. Then logic in the MainWindowViewModel determines which view to bind. The main content is then dynamic based of business logic.
For example, after installation there will be a series of views, like a wizard, that walks the user through the intial setup. Then, once up & running, what is displayed there is based off what action the user choise.
I had a conversion with a co-worker who was totally against this design because he thought that the VM's should not know about any views. He is right in that the MainWindowViewModel has a method called LoadView that accepts an enum containing the names of the content items to show.
So, if the user clicks a customer account, the click handler would pass AppViews.CustomerAccount to LoadView, and the LoadView method looks like this:
private UserControl _MainContent;
public UserControl MainContent
{
get { return _MainContent; }
set
{
if (_MainContent == value)
return;
_MainContent = value;
RaisePropertyChanged("MainContent");
}
}
public void LoadView(AppViews ViewToLoad)
{
_ViewModeBase vm = null;
UserControl view = null;
switch (ViewToLoad)
{
case AppViews.CustomerAccount:
vm = new CustomerAccountViewModel();
view = new CustomerAccountView();
break;
}
view.DataContext = vm;
MainContent = view;
}
Again, I have done this with success a few times, but I want to make sure it's a solid design.
Anyone have a better way?
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
If you really want to separate a bit more, use a DataTemplateSelector (ContentTemplateSelector property) to choose which view to display, instead of selecting it in LoadView. Instead of setting the DataContext on the View, bind the DataContext of the container to a VM property.
Either way, you'll have to use a bit of code-behind to select which view control to load... I mean, you could go through a LOT of effort to get all of that in the XAML, but in my opinion, it just isn't worth it.
|
|
|
|
|
Ok, but doesn't that require create a template for every view, instead of user controls. A user control would have its own ViewModel.
If it's not broken, fix it until it is
|
|
|
|
|
The template would, effectively, simply wrap the user control.
|
|
|
|
|
Ok, I'm not sure I understand.
A user control is its own file, correct? Whereas a template is defined in a resource dict?
What is the benefit of one over the other?
If it's not broken, fix it until it is
|
|
|
|
|
The user control would still be there as a discrete object (the View in other words). The data template would simply marry the view to a particular view model. If you look at Josh Smith's classic MVVM article[^], he demonstrates this neatly with:
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:vm="clr-namespace:DemoApp.ViewModel"
xmlns:vw="clr-namespace:DemoApp.View"
>
<DataTemplate DataType="{x:Type vm:AllCustomersViewModel}">
<vw:AllCustomersView />
</DataTemplate>
<DataTemplate DataType="{x:Type vm:CustomerViewModel}">
<vw:CustomerView />
</DataTemplate>
</ResourceDictionary>
|
|
|
|
|
Ok, I see. I'v read it, but I'll go back & re-read now.
So then which template is used is determined by some data, rather than by business logic?
If it's not broken, fix it until it is
|
|
|
|
|
I'm sort of there on this...
Can you show me how in the MainWindowViewModel this code is used? For example, if the user selects Show All Customers, how does the template above get used/loaded in the MainWindowViewModel?
I saw in his article where it says
"The MainWindowResources.xaml file has a ResourceDictionary. That dictionary is added to the main window's resource hierarchy, which means that the resources it contains are in the window's resource scope. When a tab item's content is set to a ViewModel object, a typed DataTemplate from this dictionary supplies a view (that is, a user control) to render it"
So the Content is set to a VM, not a View?
If it's not broken, fix it until it is
|
|
|
|
|
That's correct. The appropriate DataTemplate is picked because it matches the ViewModel. In other words, it looks at the DataType to pick up the appropriate DataTemplate.
|
|
|
|
|
Ah, right, forgot about just setting the DataTemplates based on VM type... Much cleaner than a DataTemplateSelector...
So, what Pete said 
|
|
|
|
|
Hey, you and me are in this WPF thing together bro. 
|
|
|
|
|
In it? Man, I'm up to my neck in it, and it's great 
Granted, I tend to stray from proper MVVM now and then, but I gotta say, WPF enables some nice-looking and stable interfaces... Never going back to WinForms
|
|
|
|
|
So I'm assuming that the VM is bound to the view automatically?
If it's not broken, fix it until it is
|
|
|
|
|
Ideally, you don't want to change the DataContext property from code. The usual method is to set the entire window to a ViewModel, and each section can have its DataContext bound to a property on that ViewModel.
MainWindow --> DataContext = MainWindowVIewModel
ContentFrame --> DataContext bound to ContentModel property (on MainWindowViewModel)
HelpFrame --> DataContext bound to HelpModel property (on MainWindowViewModel)
That way, when you change the content, all you do is change, in this example, the ContentModel property. Since the GUI control is hooked up with databinding, it'll automatically grab the new data, and switch to the proper DataTemplate.
So in short, you want to set the uppermost DataContext property once on window load, then operate exclusively through ViewModel properties.
|
|
|
|
|
I understand that, but Pete pointed me to this[^], and I'm wondering where or how in this design is the data context set?
So, if the content area is defined like this
<ContentPresenter x:Name="MainContent"
Grid.Row="2"
Grid.Column="0"
Content="{Binding MainContent}" />
In the MainWindowViewModel I would then set the MainContent property to the MainContentViewModel. How does the MainContentViewModel.DataContext get set. It won't know about the MainWindowViewModel.
Unless I'm missing something?
If it's not broken, fix it until it is
|
|
|
|
|
DataContext is inherited, so when the window itself is created, set its DataContext to a root ViewModel class. Then when you use the code you just posted, it would bind to the "MainContent" property of that ViewModel, which would be your MainContentViewModel (Or whatever you decide to call it).
The initial DataContext property for the window is set in code... After that, everything is data-bound.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
