I have a WPF application and am using NHibernate. My question is how do I manage change?
I am not completely sure about the behavior of the IsDirty.
This link describes my problem. The problem list all the information of current environment.
You are trying to address a client side problem using server side technology. Create a viewmodel and put your data in an ObservableCollection and implement the INotifyPropertyChanged interface on the entities as described here
This way you separate the Dirty() logic from NHibernate and make it a "pure" WPF/client issue. In the link it is described in both answers how you can track additions and deletions to/from the collection as well as changes to the properties of the items.
When you are ready to persists your data you hand the dirty records to NHibernate.
Related
I need some help to architect an MVVM application. This time I want to do it in the right way.
My View is bound to the ViewModel which is bound to the Model. No problem there. Displaying data is not the problem, updating it is my problem.
So when the View asks the ViewModel to update the Model (with a Command), which need to handle the logic?
In my case updating the data is not trivial, there are many calculations with many files.
Also, I really want that the Model does not know the business logic. So how to do this? A property in the Model which indicates that the he wants to be updated? Or maybe the ViewModel have to know the business logic? Is it the Best practice?
The model is really a snapshot of the state of your business data. Your non-trivial calculations can be encapsulated in services that can be abstracted behind interfaces and injected into your view model. This way your view model knows nothing of these complex processes other than calling them via interface contracts. So your command fires and your view model provides orchestration, your service provides actual business calculations and an updated model would be produced representing the new state of the system.
I am in midway implementing an UndoRedo container for a view model that contains nested properties and ObservableCollection. I am using PostSharp for Exception Handling in the application and thought of reusing it for implementing an undo-redo engine as stated in the article:
http://www.postsharp.net/aspects/examples/undoredo
Although the above article is for windowsForms which had binding limitations, I have made the engine to adopt the rich binding wpf platform and it is working nice for single properties.
I am wondering how to extend the UndoableAttribute to take care of Nested properties and collections. My tries and googling skills have proved futile till now. Any idea, or pointer to some article would be appreciated.
It really depends on what you are after. Providing undo functionality on object graphs can be quite complicated task. You would have to state more specifically what you want to achieve.
Generally you could instrument all nested objects and write some specialized collections to store all changes in some kind of global container.
We are working on providing such a functionality as part of future release of PostSharp.Patterns libraries – it should make to 3.1 or 3.2.
I'm studying WCF and WPF. I've learned a lot by doing sample projects, but I'm having trouble putting everything together. It would help if I could paraphrase my understanding of proper WCF/WPF structure and invite others to confirm or correct my ideas. Here is a very broad description of how I expect my next project to work:
My persistent data will be stored in a SQL Server database. I will create a WCF Service Library which serves as an interface to the database, solving security issues and recasting the relational data into an object-oriented entity model. My application will read data through the WCF service into a memory structure which might be customized somewhat for the needs of my application, but will basically consist of one ObservableCollection for each of the entities in my data model. Because the data will be stored in ObservableCollections, I will be able to use event procedures to respond to data changes that trigger business processes. Simple user interface elements will bind directly to the collections. More sophisticated user interface elements, like a TreeView, will require another layer, called a PresentationModel or ViewModel. In the case of a TreeView, the TreeView will bind directly to the PresentationModel, and the PresentationModel will bind directly to the collections.
Have I described everything correctly?
-TC
There is nothing technically wrong in what you wrote.
Things that feel off:
... solving security issues...
Scares me because it implies, to me at least, that you will have no security issues. I would have phrased it as
provideds a centralised system for authentication and authorisation to the data from all interfaces
I would definately make use of the MVVM pattern, allow a ViewModel to expose your collections and properties that your UI binds too, you seem to have a grasp of that pattern from what you have described.
Is WCF really required for your data layer? Have you looked into Entity Framework at all?
Simple user interface elements will bind directly to the collections.
I'd advise slightly against the above. A decent model to follow is the MVVM (Model-View-ViewModel) pattern. It sounds like you've read a bit about this considering your ListViews are going to be contained in a ViewModel. I would also have your raw data models exposed to a ViewModel, and have your View bind to that. So, for your raw data models, use them like you intend to do with ListViews.
Other than that, sounds like you're spot on.
Short question:
Do any of MS's built in Data Objects support INotifyPropertyChanged?
Long explination:
So I'm going to be displaying alot of data with databound controls.
The data is going to be chaging somewhat frequently with user interaction.
The application is a basic windows form app.
Rather than wire up events for all the data to the display controls I'm hoping that I can use data objects that implement INotifyPropertyChanged, that way the controls don't need to know the how, when or why their data changed just that they need to update themselves.
Sanity check:
Am I even barking up the right tree here?
The point of INotifyPropertyChange is to report property changes. To that extent, it's supposed to be implemented by specific model classes, not by general-purpose data objects. A more general solution for such objects is provided in form of PropertyDescriptor.AddValueChanged - since PropertyDescriptors can represent "virtual" properties, such as DataRow fields, or WPF attached properties.
I have been working for a few months on a rather large windows forms app, and we are using DataBinding and INotifyPropertyChanged for everything. It works really well, and I have no real problems to report. We are using our own classes, because there really isn't a data layer in this application, so I don't know for sure about the MS data classes.
BindableCollection< T > implements INotifyPropertyChanged
Following on from this initial investigations on Silverlight architectures, I have some new requirements to consider.
We expect our Silverlight client UI to be graphically heavy, with a GIS interface, multiple charts, gauges and datagrids arranged in a Widget style fashion. New widgets will be dynamically generated by the user.
Suppose a user wanted to dynamically create a chart widget from an existing datagrid widget pre-populated with data. It appears to me that if we were using a MVVM pattern with the view model on the server, this would result in an unnecessary call back home when the required data is already located in the client.
Now obviously the server needs to know about this new chart widget on the client, but how do I create the widget in the client first (with the existing client side data) and then notify the server about the new changes?
In our intranet, the network link between the client and the server is not particularly good so performance is critical.
It seems from my initial research that the common Silverlight architecture patterns call for as much of the business logic to be pushed back to the server. I understand the reasoning for this, but fear that it will really hurt the usability of our application.
Are there particular design patterns that address this issue? Is this 'client-binding' supported within MVVM, Prism or other common Silverlight architectures?
Is there a more formal name for what I am attempting to describe?
I am quite new to both Silverlight and design patterns such as MVVM, so please correct me if any of my assumptions are wrong.
The MVVM pattern is for separation of concerns. It does not define how or where you get your data.
The model, is data. It can be data you get from any arbitrary source. In silverlight, the most common way to get data is via a webservice (SOAP/REST). But your model can be any data from anywhere.
The view model is just another class that probably implements the INotifyPropertyChanged interface (So you bindings can automatically be updated). This class is an abstraction for your view's data. Let's pretend it has a string property called "FirstName".
The view is your UI (A user control in SL). You setup your bindings here to your ViewModel. IE, .
The view and view model are put together when you set your views DataContext. myView.DataContext = new MyViewModel(); There are many ways to set the DataContext depending how you want to set things up.
Prism is just a framework to help write decoupled applications in WPF/SL. It does not enforce the usage of any UI pattern (ie, MVP/MVC/MVVM). What it does come with is a bunch of classes can be used to assist with MVVM development, such as a mediator (EventAgggregator) and a dependency injection container (Unity).
So enough digressing...What I would suggest, is you have a web service where you can get all your data. You SL app would get that data (most likey the web services will be called in the view model). That data now exists on the client side and you can setup your VM to bind to this data in your view.