I have several classes that exist persistently throughout application lifetime and can contain any code a programmer might need to run (stuff like for example that is executed when a user resizes the app window). These classes are basically empty templates and aren't for a single task (uh oh, sounds like bad OOP, but please stay with me here). There are several of these classes in my framework and which one is integrated into the rest of the framework depends on the build target (web, desktop, mobile, etc). Currently these classes are named:
AppModule
AppDesktopModule
AppAndroidModule
etc.
But I'm not happy with this naming. I'd like to give them a name that somehow clarifies that these classes are persistent throughout app lifetime. Does anyone have ideas for a better naming?
Related
I've set up a very simple (Universal Windows) App in C++/WinRT.
It's just App <- MainPage <- DataViewModel <- Data for now.
MainPage has some Sliders etc. which are bound (x:Bind) to DataViewModel, which contains an instance of Data. Working fine so far.
However, the Data is a member of DataViewModel. This seems to be an obvious code smell. Data should not be "owned" by the GUI. All Examples/Samples I've come across seem to be set up like this, though.
I also want to run a background thread (pure C++ code) that works with one and the same instance of Data.
The question: Who "owns" Data. How do I connect things? How to pass the reference?
My best idea so far: The App class itself should just own the one instance of Data. The MainPage ctor should take a Data& and pass it on to the ctor of DataViewModel. However, I don't seem to be able to write a custom ctor for MainPage, because there's generated code involved.
Just pointing me to well coded Sample App would also be appreciated.
IInspectable (in the comment above) makes a noteworthy point: "Ownership really only matters when non-static lifetimes are involved. If Data represents data with static lifetime then there's nothing inherently wrong with exposing it through a static App class member."
In this vein, don't limit your thinking of Data (i.e., the model) to just object(s) which some other object owns. The model should be thought of as a wholly independent component.
Let me approach this notion from another angle. Most people will readily describe MVVM as three independent "layers" or "components" or what have you, wherein the model "doesn't care" about the view model, which in turn "doesn't care" about the view.** In code (as you have seen yourself), you're probably going to find some clear cut ownership patterns to reflect that basic premise. For example, if we're following the the "view-first" approach like the Microsoft samples, you'll start with your App object, which owns an instance of a view object, which in turn instantiates a view model instance.
But the key to MVVM is not who owns whom, it's the relationships between those layers. If you wanted to, you could write a program where, say, the views and view models were all static members of the App class and still have a (conceptually) textbook MVVM structure once everything is hooked up. From that perspective, it doesn't matter where ownership resides.
Now, the thing about Microsoft samples like the Photo Editor is that ultimately they're just demonstrations of how things can work, not a treatise on design patterns. Consider when your data is coming from a database or a web service. Where do you draw the conceptual line between model and view model? The question may sound pedantic, but the way you evaluate these things influences your design decisions.
Which brings me back to your specific question. If it seems like code smell to you when examples you find online stick the model data any old place, you're not wrong. In "real life," the model can be an entire API, not just one illustrative class. You'll potentially have an elaborate subsystem delivering data to you that depends on services completely separate from your application. Or it might be an opaque third-party API that you're calling into via global functions, etc. Just remember that the key isn't "ownership," it's (the conceptual) "relationship." ***
** As a side note, you mention Data being a member of DataViewModel and describe this as Data being "'owned' by the GUI." Ideally, the view model should have no inherent ties to the UI, just application logic. Don't think of it as an extension of UI functionality.
*** But please don't take this post to imply that the actual implementation of the MVVM paradigm isn't important. That's true of any design pattern. The exact form that implementation takes depends on the specific application and whatever your boss wants you to do. All I'm saying is, don't get hung up on ownership. :)
I read a lot of ViewModel derived from AndroidViewModel, which then requires of course an application reference.
class SomeViewModel(application: Application) : AndroidViewModel(application)
But why would one do this? It hurts me to see application handed over to ViewModel. What would be an acceptable use case for this?
If there is any reason to use AndroidViewModel, can one not derive from ViewModel + use dagger2 for the application inject?
Not all codebases are created equal. AndroidViewModel can be a useful tool for incremental refactoring in "legacy" codebases that don't have many abstractions or layering in place (read: Activity/Fragment god objects).
As a bridge from a "legacy" codebase, it makes sense to use it in this situation.
But why would one do this? It hurts me to see application handed over to ViewModel. What would be an acceptable use case for this?
The use case for AndroidViewModel is for accessing the Application. In a "legacy" codebase, it's relatively safe to move "Context/Application-dependent code" out of Activities and Fragments without requiring a risky refactor. Accessing Application in the view model will be necessary in that scenario.
If there is any reason to use AndroidViewModel, can one not derive from ViewModel + use dagger2 for the application inject?
If you're not injecting anything else, then at best it's a convenient way to get an Application reference without having to type cast or use any DI at all.
If you're injecting other members, be it with a DI framework or ViewModelFactory, it's a matter of preference.
If you're injecting a ViewModel directly into your Activity/Fragment, you're losing the benefits the platform is providing you with. You'll have to manually scope the lifecycle of your VM and manually clear your VM for your UI's lifecycle unless you also mess around with ViewModelStores or whatever other components are involved in retention. At that point, it's a view model by name only.
Because it requires an application reference, it can provide Context which can be useful (e.g: for a system service).
See - AndroidViewModel vs ViewModel
While working on a Symfony 2 based WebApp project and I came up with a general OOP question:
A WebApp project based on the Symfony Framework is sperated into different Bundles. This is basically just an alias for Library, Assembly, etc. in other Frameworks: Code/Classes that belong together somehow are organized within the same Bundle.
To be re-usable, different Bundles should be (more or less) independent from each other.
My WebApp Project contains (beside other) the follow two bundles:
AppBundle: Containing the core model and layout, etc.
ShopBundle: Containing all classes and code necessary to purchase subscriptions (access to the WebApp)
The User class, that represents the entity of an logged in user, is stored in the AppBundle.
Now I need a new method, that tells me, whether a users has placed a purchases or not.
Big question is: Where should I implement this method?
Solution 1: Add hasPurchases() to User class
This sounds reasonable, since the question "Does user XY has purchases" is of course a question to user XY. BUT: If the User class implements this method, the class has to know/use the ShopBundle and would thus be depended from this bundle. This would be a disadvantage, this I would like to avoid coupling between the bundles.
Solution 2: Implement hasPurchases($user) in some external class
To avoid any dependency of the User class from the ShopBundle I could move the method to some external class. The method would receive the user object as parameter and then check if there are any purchases for that user.
The advantage would be, that the User object still does not need to know anything about the ShopBundle. However I would just move the coupling problem to another class: Now the class XY that implements hasPurchases($user) needs to know both the User class and the ShopBundle.
So, what is the correct solution here?
I'm working on a Durandal SPA, and I've setup some views and viewmodels. However, I thought the MVVM architecture would also involve a "model" segment (Model, View, ViewModel--right?).
However, the Durandal Getting Started page says this under the "Organization" section:
If you expand the App folder, you will find the source for the entire
SPA sample. Here's the high level organization you will find:
App
durandal/
viewmodels/
views/
main.js
Absent from this structure is a "models" folder. Where are you supposed to put your models in a Durandal app?
I've looked at some other sample apps, and I can't find a "models" folder (or anywhere that models are residing) for any of the sample apps I've reviewed.
The "models" folder (which isn't there) seems to me to be a critical part of a Durandal app. However, it's not there--and therefore, I am questioning my understanding of how Durandal (and MVVM apps) are designed. There is surely something I am not understanding... can someone fill me in on the intended structure of a Durandal app, and where to put your model objects?
The answer is that Durandal only gives you the structure necessary to run, and nothing more. It uses a viewmodels and views folder, so it tells you to make one. Durandal doesn't use a models folder, you do.
I make one in my projects. If you feel like it fits your dev style, you can and should make one yourself.
Notice that it also leaves no place for code that is not a viewmodel, which surely will exists in any application. I highly recommend making a modules folder for this purpose.
Don't think that the only things you can or should do are the ones you see done in the Durandal tutorials. You are the developer. You will have to build on top of what Durandal provides, and this means making your own choices.
In my applications, the models have always been defined by the REST services or WebAPIs that the app makes requests against. I haven't had a need to define those models in the application code. The models are defined by the server/service side.
When using something like Breeze, the model is just a JSON representation of your entity models in your database.
If you feel more comfortable defining those models in your application code, you are more than welcome to. If I did something like that, I would put it in a App\models folder as you suggested. I don't think you will need to do this most of the time, though.
I'm about to develop this small website, its basically a simple web app to store informations about patients for a doctor.
The company i have got the assignment from demands an introducton with a class diagram, honstly, i have done this already but only for standalone apps, i'm very new in designing class diagrams for websites.
What i'm using is the Ivar Jacobson's iterative metho with usecases, where a usecase includes:
Actors, scenario (representing user-system interactions when all goes fine), and worse case scenatio (solutions when something goes wrong).
By applying this i came to a good conclusion, a well prepared class diagram.
My problem is that i'm doubting whether or not i should include jsp views and servlets(in my case action beans since i use Stripes) in the diagram, i mean, the bridge between the business-classes and the user are the jsp-views and the provided info are going to be processed by the servlets (or action beans), would you include them in the class diagram?
For a small project tis might be not that relevant but what if you have a project with 30 views and 20 servlets, the diagram would become messy and huge.
Do you have some tips about it?
Thank you
If the only reason you need the class diagram is to satisfy the client, best find out what they're looking for first.
If however they're not specific (and ignoring the cynical options) I'd suggest the following:
Create a "Domain Model" diagram. i.e. capture the concepts in the domain and their inter-relationships. So Doctor, Patients and associated stuff.
Don't create a "design" class diagram - i.e. no jsps, servlets, etc. If necessary create a simple architecture picture instead showing how the application is layered.
Rationale: a domain model is good for checking scope and verifying domain rules (relationships). A "design" class diagram only obfuscates that. A proliferation of jsps, controllers, etc. hides the underlying architecture pattern while distracting from the useful stuff in the domain model.
hth.