I am following the example from Local Database for Windows Phone. From it, I learned how to create a local database in my app and pull a data to a page.
What I am looking for now is to show the data not in one page but three pages of my app. So, what are my ways to do this? Can I make an object in app.xaml and access it in the pages?
Kindly advise me.
thanks.
The approaches all boil down to your views on the architecture and how testable you want your application to be.
Whilst you could put some reference to the data context on your application object, you're then increasing the linkage between the view-models and the views; Arguably nothing in the view-models needs to know anything about anything in the views (and I'm in the camp where all xaml counts as part of the views). With this in mind, one alternate would be to have something in your view-models (or even your models) that is a static class that exposes application level objects (in a manner that is unit-test friendly, and perhaps even sharable amongst platforms) and allows any of your view-models access to that datacontext and construct any of your models, etc.
Related
I have a WPF Application where I register many users in my apps inner Data Base. I have many classes that would like to query which user is logged in currently.
I wonder which is the best architecture for this kind of scenario.
So far I can think of:
A Singleton object storing the current logged in User.
Use Dependency Injection and pass an object containing all the login information for every class that needs it (and to some classes that won't need it directly, but might have to pass it along to another one later).
Singleton has its disadvantages, and DI could lead to many dependencies being shared all over the place and could be a maintenance nightmare on the furniture. I wonder if there is a better solution for this issue.
In my WPF application I'm using the MVVM pattern and the repository pattern. I have a repository that provides a list of aircraft objects. From a user perspective, I want to display these aircrafts in several different ways (e.g. on a map, in lists, in textual form, etc..), and also allow the user to filter the objects. To achieve this I have built views and viewmodels for each of the different ways of representing the data.
My problem now is that I'm not sure what the best practice is for making the list of aircraft objects available for all the different viewmodels. Here's some of the alternatives I've considered:
1.Inject the repository into each viewmodel, and then get all the objects from the repo.
2.Inject the repository into a MainViewModel that retrieves all the objects from the repo, and then inject the object collection into all other viewmodels that needs it.
So in sum: I have a set of viewmodels that all make use of the same collection of model objects. What is the best practice for sharing this collection between the viewmodels when using the repository pattern?
In a WPF application I'll typically create service objects which encapsulate repositories which in turn contain a session object each, but I use dependency injection to inject the actual implementations. One of the major benefits of doing this is that everything can be easily mocked for unit testing, but another one is that you now have total control over the scope of these objects. If you're pulling your data from a database then you'll have different strategies for session management depending on whether you're developing a windows app vs a web site (say) and in enterprise applications this requirement will change even within the same code base. There's a good article on Germán Schuager's blog discussing the pros and cons of various session management strategies but for WPF applications using one session per form seems to be a good one. If you're using something like Ninject then you simply scope your ISession object to the view model for your top-level "page" and then all the objects within the logical hierarchy for that page can create their own repositories without needing to know about each other. Since they're all sharing the same session object they're also sharing the same entities in the repository cache and thus the model is now being shared by multiple view models. The only thing that remains is to add property notification to the entity classes in your domain layer so that changes made by one view model propagate through to the others, but that's a topic for another post (hint: your DB layer should provide some mechanism for injecting your own wrapper proxies to add property change notification automatically using things like Castle DynamicProxy etc).
The general rule of thumb is that EACH view should have it's own ViewModel, you can reuse ViewModels via inheritance or adding properties but again a view "DESERVES" it's own ViewModel.
You can have your views leverage interfaces, your viewmodels can implement interfaces.
We have a complex composite financial application where we needed to share various model objects across viewmodels, So we took an approach: we created a high level Model Object which holds collections of other model entities. This high level model is returned/populated in servicelayer. We share this high level model object in many viewmodels and with many PRISM modules using event aggregator .
So in your case you may have a AircarftsData Model, which can maintain collection of aircrafts. you can populate this model using your repository. Then You can pass this AircarftsData in various viewmodels.
We have shipped our application in production with this design and faced no issues as such. One thing you might want to be careful of Memory leakage of this Model object. If somehow any child object of this Model is leaked in memory then whole high level model may remain in memory.
Your data should be located in some place... (Service, Database, File, Etc...).
In that case, you should have a class which manage yours client requests:
GetAllAircrafts, Create, Update, Etc...
This class somtimes called XXXService.
I think that this is where you should expose your collection of models.
This service can be injected to the view models and share the collection of models through a get property (Maybe as a read only collection...?)
Good luck !
We're getting started on a new application that will run on several platforms (web, mobile, tablets etc). The goal is keep the models and controllers the same for all the platforms. Only the views will be changing. For example, if I have Roles view (and RolesCtrl) and Persons view (and PersonCtrl) on different pages (roles view redirects to persons page with role id as query string or something) on one platform, these two views might be combined into a single page (role id should not transfer to person page but to another view on the same page) on a different platform. I understand I can have separate divs and keeping the controllers intact, but since the UI flow is different for different platforms, how can that be handled? Is it feasible to keep the controllers unchanged?
Is this the right approach? Any help is greatly appreciated.
I would suggest proving this out by creating a small project to implement some piece of functionality backed by a service that AngularJS will communicate with.
It sounds like you might have some behind the scenes complications here. I would suggest that if you do use AngularJS to make sure all of the developers are making their HTTP communications done through AngularJS and not try to go work around it.
From my short experience with AngularJS I think it would work fine and may actually make things simpler because of it's easy single application model.
I would like to use db4o for persisting my business object in Prism aplication. How should I maintain IObjectContainer lifetime? As I know from documentation, when I load object with one container I should save it with the same one. So maybe some kind of singleton scope should be right. But doesn't container keep reference to every object which goes through it and because of this doesn't it cause something like memory leak?
I read something about Conversation per Business Transaction, but it was for nHibernate and I guess nHibernate's session and db4o's container are totally different things.
Just for sure, I am talking about desktop application with embedded db4o. So, no server/client.
For desktop applications it's usually easier to have a global container. That way you just can store / update objects without any issues. So singleton scope should be the right one.
The db4o container only holds weak references to objects. That means it should never prevent objects from being collected.
I my desktop App with db4o we have a single object container. After each logical operation we just commit to persist all changes.
I am writing an application, there are various forms and their corresponding datamodules.
I wrote in a way that they are using each other by mentioning in uses class(one in implementation and another in interface to avoid cross reference)
Is this approach is wrong? why or why not i should use in this way?
I have to agree with Ldsandon, IMHO it's way better to have more than one datamodule in your project. If you look at it as a Model - View - Controller thingie, your DB is the model, your forms would be the Views and your datamodules would be the controllers.
Personally I always have AT LEAST 2 datamodules in my project. One datamodule is used to share Actions, ImageLists, DBConnection, ... and other stuff throughout the project. Most of the time this is my main datamodule.
From there on I create a new datamodule for each 'Entity' in my application. For example If my application needs to proces or display orders, cursomters and products, then I will have a Datamodule for each and everyone of those.
This way I can clearly separate functionality and easily reuse bits and pieces without having to pull in everything. If I need something related to Customers, I simple use the Customers Datamodule and just that.
Regards,
Stefaan
It is ok, especially if you're going to create more than one instance of the same form each using a different instance of the related datamodule.
Just be aware of a little issue in the VCL design: if you create two instances of the same form and their datamodules, both forms will point to the same datamodule (due the way the VLC resolves links) unless you use a little trick when creating the datamodule instance:
if FDataModule = nil then
begin
FDataModule := TMyDataModule.Create(Self);
FDataModule.Name := ''; // That will avoid pointing to the same datamodule
end;
A data module just for your table objects, if you only have a db few tables, would be a good one to be the first one.
And a data module just for your actions is another.
A data module just for image lists, is another good third data module. This data module only contains image lists, and then your forms that need access to image lists can use them all from this shared location.
If you have 200 table objects, maybe more than one data module just for db tables. Imagine an application that has 20 tables to do with invoicing, and another 20 tables to do with HR. I would think an InvoicingDataModule, and HRDataModule would be nice to be separate if the tables inside them, and the code that works against them, doesn't need to know anything about each other, or even when one module has a "uses" dependency in one direction, but that relationship is not circular. Even then, finer grained data module modularity can be beneficial.
Beyond the looking glass. I always use Forms instead of DataModules. I know it's not common ground.
I always use Forms instead of DataModules. I call them DataMovules.
I use one such DataMovule per each group of tables logically related.
I use Forms instead of DataModules because both DataModules and Forms are component containers and both can effectively be used as containers for data related components.
During development:
My application is easier to develop. Forms give you the opportunity to view the data components, making easy to develop those components.
My application is easier to debug, as you may put some viewer components right away so you may actually see the data. I usually create a tab rack, with one page per table, and one datagrid on every page for browsing the data on the table.
My application is easier to test, as you may eventually manipulate the data, for example experimenting with extreme values for stress testing.
After development:
I do turn form invisible. Practically making it a DataModule, I enjoy the very same container features than a datamodule has.
But with a bonus. The Form is still there, so I may eventually can turn it visible for problem determination. I use the About Box for this.
And no, I have not experienced any noticeable penalty in application size or performance.
I don't try to break the MVC paradigm. I try to adhere to it instead. I don't mix the Forms that constitute my View with the DataMovules that constitute my Controllers. I don't consider them part of my View. They will never be used as the User Interface of my application. DataMovules just happen to be Forms. They are just convenient engineering artifacts.