Related
Should methods that manipulate the Model class members be implemented in the Model or in the Controller? Does it depend on how "heavy" this manipulation is ?
By "manipulation" I mean:
get a class member
make a long calculation based upon this class member
return another value which relates to this class
For example, a Board class which hold a cell matrix member.
Now I want to implement a method which returns all the surrounding cells according to specific cell location.
Is the model or view responsible to for implementing the above ?
If this question belongs to another Stack Exchange QA site I will welcome the recommendation to move my post to that site.
Keep your controllers thin, don't let them do much, this aligns with the Single Responsibility Principle in SOLID for Object Oriented Design. If you have fat controllers, they become hard to test and maintain.
As for the models, I used to have dumb models before that did nothing but to map to database tables and that was inspired by most of the sample applications that you see on the web, but now I don't do that.
I (try to) follow the principles from Domain Driven Design, where models (entities in DDD terms) are at the center of the application, they are expected to encapsulate behaviour related to the entity, they are smart models (so yes, the logic related to an object will live with it in that case). DDD is a much bigger topic and it is not related directly to MVC, but the principles behind it helps you better design your applications, there is a lot of materials and sample apps available if you google DDD.
Additionally, Ruby On Rails community - which seems to inspire most of MVC frameworks - also seems to have a hype around having Fat Models and Skinny Controllers.
On top of that, you can add View Models to your mix which I find helpful. In this case, you can have a ViewModel to represent a dumb subset of your model(s) just to use for generating the view, it makes your life easier and further separate your Views from your Models so that they don't affect your design decisions unnecessarily.
What you call "model" is are actually domain objects. The actual model in MVC is just a layer, not concrete thing.
In your particular example, the Board should have a method that returns this list. I assume, that you are actually acquiring it because you then need to do further interaction with those cells.
This is where the services within the model layer comes in to play. If you use them, they are the outer part of model layer and contain the application logic - interaction between different domain objects and the interaction between the persistence (usually either data mappers or units of work) and domain objects.
Let's say you are making a game, and you and player performs and AoE attack. Controller takes a hold of service, which is responsible for this functionality and sends a command: this player aimed AoE in this direction, perform it.
Service instantiates Board and asks for surrounding cells of the target location. Then it performs "damage" on every cell in the collection that it acquired. After the logic is done, it tell the Unit of Work instance to commit all the changes, that happened on the Board.
Controller does not care about the details of what service does. And it should not receive any feedback. When execution gets to the view, it request from model layer the latest changes and modifies the UI. As the added benefit - services let you stop the business logic from leaking in the presentation layer (mostly made up from views an controllers).
The domain object should contain only methods, that deal with their state.
I think this has little to do with MVC, and a lot more to do with regular software engineering.
I personally wouldn't hesitate to stick trivial calculations in a model, but would be extremely wary of fat models.
Now, the fact that MVC stands for Model View Controller doesn't necessarily mean that everything should be either a view, a model or a controller. If you feel the need to move responsibilities to a separate class that doesn't really qualify as an M, a V or a C, I don't see why you shouldn't do it.
The way you implement it is up to you. You could either use this separate class as a "top level" (for lack of a better term) object, or make a method of the model delegate to it, so as to hide the fact that you're using it. I would probably go for the latter.
Everything is debatable, though. Everybody and their sister seem to have a different opinion on how to do MVC right.
Me, I just consider it a guideline. Sure, it's a great idea because it leads you to a better separation of concern, but in the end—as it always happens—there's no one-size-fits-all way to apply it, and you should not be overly constrained by it, to the point where everything has to be either a view, a model or a controller.
As per best practice we should use properties for Calculated fields with get access only. example public double TotalCost {
get
{
return this.Role.Cost * TotalHour;
}
}
I've mulled over Design Patterns for some time now and I am just starting to see how I might actually begin incorporating some of these more deliberately in my development work. However, I am still confused about their treatment of MVC in the beginning of the book and how it relates to the rest of the book.
Most of the frameworks I have worked with - Spring, Yii, ASP.NET, and even Objective-C Cocoa (UIKit) - cater to the MVC paradigm. I get MVC because to me it is a useful way of classifying objects and how they should message or interact with each other. Plus, these frameworks kind of force it upon you even if you are not setting out to think in the MVC way.
I also feel that I understand the premise of Design Patterns: they really don't like subclassing, they love abstract interfaces, and they strive for loose coupling. I can't say I fully understand all of the patterns yet or how they are useful, but I am getting a feel for it.
My question is this: what is the interplay between MVC and design patterns? What were they getting at in the first chapter of the book with the MVC application example? Are certain design patterns just not relevant in the MVC paradigm? I wonder, for example, how the Command pattern is supposed to fit into MVC. It seems incredibly useful, but do we create a CommandModel and CommandController to send to other controllers? Do we just create a Command object as prescribed in the book? Basically, I am wondering if the ideas of MVC and Design Patterns are wholly disjoint and I just don't understand, or if there are some patterns that do not fit into the mold.
My personnal opinion is that MVC is a simplified version of the Observer Pattern which is a simplified version of the Mediator Pattern.
MVC: One Model, One view, the Controler manages the communication between them.
Observer Pattern: One Model, Multiples views ( observers/subscribers ), and the publisher manages the communication
Mediator Pattern: Several different Models, Several views, and the mediator manages the communications between them.
The MVC in the GoF book is for the desktop, it uses the observer pattern to update views. The command example in the GoF book is for an editor.
There are other flavors of MVC where the use of other design patterns may not be obvious:
What is the difference between MVC and MVVM?
Presentation abstraction control
The GoF book says:
...
Taken at face value, this example reflects a design that decouples views from models. But the design is applicable to a more general problem: decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others. This more general design is described by the Observer (page 293) design pattern.
Another feature of MVC is that views can be nested. For example, a control panel of buttons might be implemented as a complex view containing nested button views. The user interface for an object inspector can consist of nested views that may be reused in a debugger. MVC supports nested views with the CompositeView class, a subclass of View. CompositeView objects act just like View objects; a composite view can be used wherever a view can be used, but it also contains and manages nested views.
Again, we could think of this as a design that lets us treat a composite view just like we treat one of its components. But the design is applicable to a more general problem, which occurs whenever we want to group objects and treat the group like an individual object. This more general design is described by the Composite (163) design pattern. It lets you create a class hierarchy in which some subclasses define primitive objects (e.g., Button) and other classes define composite objects (CompositeView) that assemble the primitives into more complex objects.
MVC also lets you change the way a view responds to user input without changing its visual presentation. You might want to change the way it responds to the keyboard, for example, or have it use a pop-up menu instead of command keys. MVC encapsulates the response mechanism in a Controller object. There is a class hierarchy of controllers, making it easy to create a new controller as a variation on an existing one.
A view uses an instance of a Controller subclass to implement a particular response strategy; to implement a different strategy, simply replace the instance with a different kind of controller. It's even possible to change a view's controller at run-time to let the view change the way it responds to user input. For example, a view can be disabled so that it doesn't accept input simply by giving it a controller that ignores input events.
The View-Controller relationship is an example of the Strategy (315) design pattern. A Strategy is an object that represents an algorithm. It's useful when you want to replace the algorithm either statically or dynamically, when you have a lot of variants of the algorithm, or when the algorithm has complex data structures that you want to encapsulate.
MVC uses other design patterns, such as Factory Method (107) to specify the default controller class for a view and Decorator (175) to add scrolling to a view. But the main relationships in MVC are given by the Observer, Composite, and Strategy design patterns.
...
MVC is a pattern. But it only covers a small aspect of a web application. Another common pattern that gets used with MVC is the Repository. These are more architectural patterns.... their scope has a bigger impact on the overall project.
the GOF patterns will introduce themselves in little ways all over the place. They can help build MVC infrastructure depending on design choices. eg, Strategy gets used a lot so you can plug in different ways of doing things like "authentication" etc.
You don't have to use the patterns as they are, they don't even have to be the exact same code structure. Its more the design principle / goal of the pattern that you employ in the design.
MVC is an architectural pattern. It perfectly fits with other design patterns like Command Pattern. But you do not apply patterns just because they exist and they are written in an authoritative book. You apply patterns when you have a programming/design problem and there is a way to solve that problem that was discovered by someone else and was written down. The way to solve a problem is a pattern. For example, you have an application that saves data to the database. Data to be saved is quite complex: some records must be inserted, some records updated and some deleted. The sequence of steps is important because the records to be inserted into one table depend on records to be inserted into another table. So, a database transaction must be used. One of possible ways to implement the transaction is to use Command Pattern. The way to do it is very well explained in Larman's "Applying UML and Patterns" book (chapter "Designing a Persistence Framework wth Patterns", section "Designing a Transaction with the Command Pattern" - scroll down to the page 556). PersistentObject is an abstract Model class there. All other Model classes extend it. In that example MVC is implemented in the UI, Application and Domain layers but Command is implemented in the Persistence layer. These patterns help to solve different problems and they are mutually supportive in that example.
I work on an ASP.NET MVC 3 application where branches in version control have been created for each country. This makes it difficult sync changes between the branches and the problem will increase as the number of countries increases. I have read about branching by abstraction but have never actually used it so I'm struggling to comprehend how this would be actually be implemented in a reasonably complex project.
Can anyone explain how branching by abstraction can be done for an ASP.NET MVC application where the abstraction is a country, and the application is a n-tier type affair with service and data layers?
A few of the things I can't get my head round are:
Abstracting view stuff. E.g. The aspx/cshtml files, javascript, css
etc.
Abstracting controllers
How do you manage the extra complexity of having all your for code
every country in one branch? (Note, by one branch I mean the default branch, mainline, whatever you want to call it)
How you you manage feature toggles for each country? E.g. Potentially you could have many many features for each country that were not ready for release and controller by a toggle)
How do you select the appropriate country when deploying?
How do you run unit tests for country specific functionality?
UPDATE
I'm not just talking about language changes. Much of the service layer logic for each country is the same, but in certain key areas it's different, likewise for the data layer. Also view content and layout can vary, javascript can vary and controller logic can vary.
Why do you use branches to handle localization? imho it's madness.
There are several ways to do localizations without having one code base per language.
For instance. By making your own view engine on top of an existing one you can load views from external assemblies. Or you can create one view per language.
You can also use string tables in your views to make them localized.
Abstracting view stuff. E.g. The aspx/cshtml files, javascript, css etc.
Javascripts: I have one javascript with all my logic which uses variables instead of strings to show messages. In this way I can load another javascript before the logic script (for instance myplugin.sv.js before myplugin.js to get the swedish language.
The most common way for aspx/cshtml files is to use string tables in them.
Localize css? Why?
Abstracting controllers
huh? Why? Use string tables here too.
How do you manage the extra complexity of having all your for code every country in one branch?
Don't use branches.
How you you manage feature toggles for each abstraction?
huh?
How do you select the appropriate country when deploying?
Use the same site for all languages. Either use the IP address, Accept-Language http header or the user's language preference to select language. Language is specified by setting Thread.CurrentThread.CurrentCulture and Thread.CurrentThread.CurrentUICulture
How do you run unit tests for country specific functionality?
Don't. The logic should be the same.
Update in response to your comment
I've written my fair amount of systems where content is dynamically loaded into the application/service. I've never used different code bases even if different customers use different features in multi-tenant systems (SaaS).
First of all, you need to accept two things:
a) All content is loaded at all time (not talking about translations, but features).
b) Use proper/standard localization methods, but no need to translate all features to all languages.
What you do is simply control which content to load and use standard techniques to get translated features. The control is made by either checking the current language (Thread.CurrentThread.CurrentCulture.Name) or any homebrewn control.
Ask new questions to get more details.
Update 2
I wouldn't rely on the IoC to provide language specific features, but use reflection and a FeatureProvider class to do that for me.
For instance, let's say that you have a feature called ISalaryCalculator which takes into account all local tax rules etc. then I would create something like this:
// 1053 is the LCID (read about LCID / LocaleId in MSDN)
[ForLanguage(1053)]
public SwedishSalaryCalculator : ISalaryCalculator
{
}
And have a FeatureProvider to load it:
public class FeatureProvider
{
List<Assembly> _featureAssemblies;
public T GetLocalFeature<T>()
{
var featureType = typeof(T);
foreach (var assembly in _featureAssemblies)
{
foreach (var type in assembly.GetTypes().Where(t => featureType.IsAssignableFrom(t))
{
var attribute = type.GetCustomAttributes(typeof(ForLanguageAttribute)).First();
if (attribute.LocaleId == Thread.CurrentThread.CurrentCulture.LCID)
return (T)Activator.CreateInstance(type);
}
}
return null;
}
}
And to get the feature (for the current language):
var calculator = _featureManager.GetLocalFeature<ISalaryCalculator>();
var salaryAfterTaxes = calculator.GetSalaryAfterTax(400000);
In a simple scenario (CMS/not much or shared business logic) you are dealing with just content in different languages and:
Layout (left to right vs right to left) - you will have two CSS files
Localized (translated) content
Layout CSS can be in separate files and be pulled in depending on the User Account's culture or site region setting.
Localization can reside in different assemblies - one for each culture or in separate string table files (as already mentioned).
In a more complex scenario, where you are developing an application for sensitive cultures and regions where:
You have to be careful about the content you display - for example an image can be very offensive in one country but perfectly fine in another country.
Different business logic (e.g. think financial application, etc)
Most of the content issues you can solve with CSS, but even if you need heavily customized views as has already been mentioned you can create a view engine that pulls a view file based on the current culture (e.g. Index.en-Us.cshtml, Index.ru.cshtml, etc)
For the different business rules you must have a good design and architecture utilizing Inversion of control (e.g. dependency injection) and patterns such as the Strategy, state, Template method, etc. Given that you have that in place you will be able to create an IoC container project/assembly per culture at run time and your UI will be unaware of the difference since it will be simply consuming some services defined by those interfaces.
Slightly more tricky if your ViewModels are significantly different between cultures, but if they are you probably want to maybe split View + Controller per culture in different assemblies and again use IoC to configure the routing at run time initialization.
Clearly deploying multi-cultural sites is more complex than non-such and no matter which way you go (site instance per culture or one site instance for all cultures) you will probably want to invest in some tooling to be able to script multi-culture deployment.
And last - regarding the unit tests - if you already have a good IoC based design testing per culture will be a matter of using and configuring the right dependency container prior to running a set of unit tests.
With such a setup the teams of developers should be working in relatively self-contained environment, since your project will be logically and physically be partitioned to support multiple teams working on separate parts of it at the same time. It also shouldn't matter whether on branches or trunk/head. Of course if everything is a big mess in just a few projects and people have to constantly merge in - you are in a very bad state and your future isn't bright.
Final words: It's not about branching - it's about design, architecture, partitioning (solutions, projects and assemblies) and last but not least about automation (build and test).
This is a little off topic, but I believe you're heading in a more difficult direction than you need to. Localization is built into ASP.NET and the MVC framework can take advantage of it also.
The short story is that you basically make a resx for each language you'd like to support. You then use Resources.Global.YourLocalizedStringPropertyName in your views.
This blog post is the long story. Scott Hanselman goes over javascript localization and other finer points. It's definitely worth a read and will probably save you incredible amounts of work to use the built in functionality instead of building it yourself:
http://www.hanselman.com/blog/GlobalizationInternationalizationAndLocalizationInASPNETMVC3JavaScriptAndJQueryPart1.aspx
I think that the terminology used in Qt with model/view controls is flawed. On their explanation page they state, that they simplified the MVC to MV by merging View and Controller and they are giving the following picture:
However I think, they misnamed the roles of objects and I think that,
What they call View with merged Controller is in fact a View only.
What they call Model is in fact Controller only.
If you really want to have a model it would be somewhere where their "Data" is.
I am speaking about usual and sane way you would use Qt model/view component in your app.
Here are the reasons:
This is typically Qt component which is used as is, without adding any Controller logic specific to your objects)
This is hardly a Model, just because you should implement several Qt methods like rowCount, columnCount, data etc. which have nothing to do with your model. In fact there are typical model methods found in Controllers. Of course, you can implement both Controller and Model logic here, but first it would be quite bad code design and secondly you would merge Controller and Model not Controller and View as they state.
As said in reason 2. if you want to separate Model logic that it is surely not the blue box on the picture, but rather the dashed "Data" box (communicating to real Data of course).
Is Qt wrong in their terminology, or it is just me who does not understand? (BTW: The reason why it is not academic question is that I have started to code my project following their naming and I have soon found out, that the code clearly is not right. It was only after that when I realized, that I should not try put Model logic in what they call Model)
Short answer
Qt's MVC only applies to one data structure. When talking about an MVC application you should not think about QAbstractItemModel or QListView.
If you want an MVC architecture for your whole program, Qt hasn't such a "huge" model/view framework. But for each list / tree of data in your program you can use the Qt MVC approach which indeed has a controller within its view. The data is within or outside of the model; this depends on what type of model you are using (own model subclass: probably within the model; e.g. QSqlTableModel: outside (but maybe cached within) the model). To put your models and views together, use own classes which then implement the business logic.
Long answer
Qt's model/view approach and terminology:
Qt provides simple views for their models. They have a controller built in: selecting, editing and moving items are something what in most cases a controller "controls". That is, interpreting user input (mouse clicks and moves) and giving the appropriate commands to the model.
Qt's models are indeed models having underlying data. The abstract models of course don't hold data, since Qt doesn't know how you want to store them. But you extend a QAbstractItemModel to your needs by adding your data containers to the subclass and making the model interface accessing your data. So in fact, and I assume you don't like this, the problem is that you need to program the model, so how data is accessed and modified in your data structure.
In MVC terminology, the model contains both the data and the logic. In Qt, it's up to you whether or not you include some of your business logic inside your model or put it outside, being a "view" on its own. It's not even clear what's meant by logic: Selecting, renaming and moving items around? => already implemented. Doing calculations with them? => Put it outside or inside the model subclass. Storing or loading data from/to a file? => Put it inside the model subclass.
My personal opinion:
It is very difficult to provide a good and generic MV(C) system to a programmer. Because in most cases the models are simple (e.g. only string lists) Qt also provides a ready-to-use QStringListModel. But if your data is more complex than strings, it's up to you how you want to represent the data via the Qt model/view interface. If you have, for example, a struct with 3 fields (let's say persons with name, age and gender) you could assign the 3 fields to 3 different columns or to 3 different roles. I dislike both approaches.
I think Qt's model/view framework is only useful when you want to display simple data structures. It becomes difficult to handle if the data is of custom types or structured not in a tree or list (e.g. a graph). In most cases, lists are enough and even in some cases, a model should only hold one single entry. Especially if you want to model one single entry having different attributes (one instance of one class), Qt's model/view framework isn't the right way to separate logic from user interface.
To sum things up, I think Qt's model/view framework is useful if and only if your data is being viewed by one of Qt's viewer widgets. It's totally useless if you're about to write your own viewer for a model holding only one entry, e.g. your application's settings, or if your data isn't of printable types.
How did I use Qt model/view within a (bigger) application?
I once wrote (in a team) an application which uses multiple Qt models to manage data. We decided to create a DataRole to hold the actual data which was of a different custom type for each different model subclass. We created an outer model class called Model holding all the different Qt models. We also created an outer view class called View holding the windows (widgets) which are connected to the models within Model. So this approach is an extended Qt MVC, adapted to our own needs. Both Model and View classes themselves don't have anything to do with the Qt MVC.
Where did we put the logic? We created classes which did the actual computations on the data by reading data from source models (when they changed) and writing the results into target models. From Qt's point of view, this logic classes would be views, since they "connect" to models (not "view" for the user, but a "view" for the business logic part of the application).
Where are the controllers? In the original MVC terminology, controllers interpret the user input (mouse and keyboard) and give commands to the model to perform the requested action. Since the Qt views already interpret user input like renaming and moving items, this wasn't needed. But what we needed was an interpretation of user interaction which goes beyond the Qt views.
I agree with you that Qt's naming is misleading. In my opinion however, the problem is not Qt's alone, but is shared by all frameworks that allow us to adhere to the principle of separation of concerns when implementing our UIs. When someone comes up with such a framework, and finds a good way to keep "things" separated, they always feel obliged to have modules that they call "Model" and others that they call "View". Over the years I have worked with these frameworks:
MFC
Qt
Swing
SWT
WPF with MVVM
If you compare how the terms "Model" and "View" are used in these frameworks, and what responsibilities the classes in the "View", the "Model", and the "Controller" (if there is one) have, you will find that there are very big differences. It would certainly be useful to have a comparison of the different concepts and terminologies, so that people switching from one framework to another have a chance to stay sane, but that would require a lot of work and research. A good read is Martin Fowler's overview.
Since there are so many different ideas what an MVC pattern can look like, which one is correct? In my opinion, the people who invented MVC should be turned to when we want to know how it is supposed to be implemented "correctly". In the original smalltalk paper it says:
The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
In light of that I would answer your three main concerns thusly:
In fact a Qt component "manages the graphical [...] output", and "interprets the mouse and keyboard inputs", so it could indeed be called merged View and Controller with respect to the definition above.
I agree that you are/would be forced to merge Controller and Model (again with respect to the definition above).
I agree, again. The Model should only manage the data of the application domain. This is what they call "data". Clearly, dealing with rows and columns for example has normally nothing to do with our applications domain.
Where does it leave us? In my opinion, it is best to figure out what Qt really means when the terms "Model" and "View" are used and use the terms in their manner while we are programming with Qt. If you keep being bothered it will only slow you down, and the way things are set up in Qt does allow elegant design - which weighs more that their "wrong" naming conventions.
The terminology isn't right or wrong, it's useful or useless.
You might change the question a bit and ask why Qt isn't more MVC-friendly. The answer to is that the early Qt developers believe that decoupling V from C in GUI applications makes for bad Vs and Cs both. QWidget's design tries to make it simple to bind mouse input interperation closely with pixel output decisions, and you can see how that's not the road towards MVC.
As Model function is to respond to requests for information, I think there is nothing wrong in defining such methods as rowCount, columnCount, etc. I think Model is some kind of wrapper for data source (no matter what is it SQL table or just an array), it provides data in standard form, and you should to define methods depends on your data source structure.
I believe their terminology is correct...although in real applications I find it can be very easy to blur the lines between model, view, and controller depending on your level of abstraction: one level's view may be a higher level's model.
I feel the confusion arises from their QAbstractModelItem class. This class isn't a model item, but rather it is an interface to a model. To make their view classes interface with the model, they had to create a generic abstract interface to the model. However, a model can be a single item, a list of items, a table of 2 or more dimensions of items, etc; so their interface has to support all these model variations. Admittedly, this makes the model items fairly complex, and the glue code to make it work with an actual model does seem to stretch the metaphor a bit.
I think that ... What they call Model is in fact Controller only.
No, their "model' is definitely not a controller.
The controller is the part of user visible controls that modify the model (and therefore indirectly modify the view). For example, a "delete" button is part of the controller.
I think there is often confusion because many see something like "the controller modifies the model" and think this means the mutating functions on their model, like a "deleteRow()" method. But in classic MVC, the controller is specifically the user interface part. Methods that mutate the model are simply part of the model.
Since MVC was invented, its distinction between controller and view has become increasingly tense. Think about a text box: it both shows you some text and lets you edit it, so is it view or controller? The answer has to be that it is part of both. Back when you were working on a teletype in the 1960s the distinction was clearer – think of the ed – but that doesn't mean things were better for the user back then!
It is true that their QAbstractItemModel is rather higher level than a model would normally be. For example, items in it can have a background colour (a brush technically), which is a decidedly view-ish attribute! So there's an argument that QAbstractItemModel is more like a view and your data is the model. The truth is it's somewhere in between the classic meanings of view and model. But I can't see how it's a controller; if anything that's the QT widget that uses it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
NOTE:
This question has been updated to provide more detail and insight than the previously.
UPDATE:
I just want to say thank you to everyone who responded. I'm still pretty much in the dark on what design pattern would work best for the Widget. Perhaps one of the Factory or Builder patterns?
I am just getting started on a new project and need to use MVC, OO and design patterns.
Here's the idea: Imagine a page that displays a set of widgets. These widgets are (usually) charts that are based off of data contained in several separate tables in the database. I use a running example of page that reports on a student's performance.
High Level Requirements
a page that displays a set of (HTML only) widgets.
widget's data will be based off a database query.
the page can be used to view separate datasets containing similarly laid out data. For example, a single page will display widgets that report on various aspects of a single student's performance.
want to see another student's performance, pull up another page. Displaying different widgets for different students is not needed (though it may be nice to have later).
There may be many students, but data contained in the database is similarly laid out for all students.
the way a widget is displayed may be changed easily (say changing a widget from displaying as a pie chart to display as a bar chart).
widgets should be able to be created quickly.
Low Level Requirements
Currently data does not change so widgets will not need to automatically update themselves.
Widgets may represent a ratio of two things (eg. a ratio of failed tests to successful tests as a pie chart), a series of points, or sometimes a single numeric value.
Development of new widgets should be a breeze, existing code need not be modified.
Framework to be used: Zend Framework, based on MVC.
There are (minimally) three things to define a widget: the dataset to report on (in the example above, the student ID), the query that describes the metric being reported, and a render mode (barchart, timeseries etc).
Here is a pass at breaking down the responsibilities of each layer of the MVC:
View: Zend views are HTML templates with PHP injected. They will contain one of several types of widgets. Widgets are of various forms including: static JPEG images (loaded from a remote site ie: <img src="http://widgetssite.com?x=2&y=3"/>, JSON based javascript widgets, or charts of various kinds (piechart, bar chart etc.)
Controller: Creates the widgets, assigns them to the view afterwards. The set of widgets that is to be displayed on a page needs to be maintained somewhere. Since I can't think of a good way to do this in the view, I'll add this to the controllers responsibilities for now. If there's a better place for this please shout. The controller will also have to handle any other input parameters and passing them to the widget. For example, the data_set id which may be passed at the url line as http:/.../report/?student_id=42
Model: The model, in the Zend Framework, is responsible for pulling the data and as such will most likely contain a class for each widget for accessing the database.
Some points:
The model here, represents the data for a particular widget. So necessarily, it will need to know what the query is going to be, in order to pull together the tables necessary to fetch that data.
There's an additional processing step that will most likely be necessary before the widget can present the data. This is dependant upon which renderer will be used. Sometimes it may require forming a url out of the data returned. Other times, a JSON array. Other times perhaps creating some markup. This can go either in the model or the controller or the view. Unless anyone can think of a good reason to move it to the controller or view, it is probably best to let this live in the model and keep the view and controller thin.
Likewise, a widget will be made up of 3 things, its parameters, its data, and its renderer.
One big part of the question is: What's a good way to represent the widget in an Object Oriented design? I already asked this once, couldn't get an answer. Is there a design pattern that can be applied to the Widgets that makes the most sense for this project?
Here's a first pass at a rather simple class for the Widget:
class Widget{
//method called by the view
render() {//output the markup based on the widget Type and interleaved the processed data}
//methods called by the controller:
public function __construct() {//recieve arguments for widget type (query and renderer), call create()}
public function create() {//tell the widget to build the query, execute it, and filter the data}
public function process_data() {//transform into JSON, an html entity etc}
//methods called by the model:
public function build_query() {...};
public function execute_query() {...};
public function filter_data() {...};
}
Looking at it, I can already see some problems.
For example, it is straightforward to pass the widget that was created in the controller to the View to render.
But when it comes to implementing the model it seems not so straight forward. Table Gateway Pattern is simpler to implement than ORM. But since table gateway pattern has one class for each model/table it doesn't seem to fit the bill. I could create a model for a particular table, and then within that, instantiate any other models needed. But that doesn't seem so to fit the Table Gateway Pattern, but rather ORM pattern. Can Table Gateway Pattern be implemented with multiple tables? What alternatives are there? Does it make sense that the controller creates the widget and the widget creates the Model?
Another issue that arises is that this design does not enable ease of widget creation. ie. Say I wanted to create a PiechartWidget, how much code can be reused? Would it not make more sense to use some OO ideas such as an interface or abstract classes/methods and inheritance?
Let's say I abstract the Widget class so only the shared methods are defined concretely, and the rest are declared as abstract methods. Revising the Widget class to make it abstract (second pass):
abstract class Widget{
private $_type;
private $_renderer;
//methods called by the controller:
//receive arguments for widget type (query and renderer),
protected function __construct($type, $renderer) {
$this->_type = $type;
$this->_render = $renderer;
$this->create();
}
//tell the widget to build the query, execute it, and filter the data
private function create() {
$this->build_query();
$this->execute_query();
$this->filter_data();
}
//methods called by the model:
abstract protected function build_query();
protected function execute_query() {
//common method
}
abstract protected function filter_data();
//method called by controller to tranform data for view
//transform into JSON, an html entity etc
abstract protected function process_data();
//method called by the view
//output the markup based on the widget Type and interleave the processed data
abstract protected function render();
}
Is this a good design? How could it be improved?
I assume writing a new widget will require at least some new code to build the query, and maybe filter the data, but it should be able to use preexisting code for almost all of the rest of its functionality, including the renderers that already exist.
I am hoping anyone could provide at least some feedback on this design. Validate it?
Tear it apart. Call me an idiot. That's fine too. I could use any forward traction.
A few specific questions:
Q1. What's the best way to implement the renderers, as part of the Widget class or as a separate class? 1a. If separate, how would it interact with the widget class(es)?
Q2. How could I improve this design to simplify creation of new kinds of widgets?
Q3. And lastly, I feel like I am missing something here with regards to data encapsulation. How does data encapsulation relate to the requirements and play out in this scenario?
For #2, if you are using WPF on windows, or Silverlight in general, consider using MVVM pattern (Model-View-ViewModel), here is explanation with a WPF implementation:
MVVM at msdn
For #1 (comments not answer): For exact implementations (and minor variations) of MVC, it really depends on what language you are using.
Another alternative to MVC is MVP Model View Presenter
Remember the goal of OO is not to cram design patterns into your code, but to create maintainable code with less bugs/increased readability.
High Requirements
- a page that displays a set of widgets. widgets are based off of data contained in several separate tables in the database.
- widget's data will be based off a database query. widget display its data in a particular way.
- widgets should be able to be created quickly.
Low Level Requirements
- Data changes, multiple charts need to change, push model (from data to ui)
- Development of new widgets should be a breeze, existing code need not be modified
Advice from design patterns basics
- MVC supports one to many notification pattern, so yes, once your widget is initialized, created and connected to the web page, it should wait for notifications from the database.
- Strategy pattern, your entire code should develop to a interface. New widgets should be added to a parametrized LinkedList (or some other data structure). That way new widget developers just implement the interface and your framework picks up these notifications without change to existing code.
Siddharth
The purpose behind all of these ideas -- MVC, patterns, etc. -- is essentially the same: every class should do one thing, and every distinct responsibility in your application should be separated into distinct layers. Your views (page and widgets) should be thin and make few if any decisions other than to present data gathered from the models. The models should operate on a data layer agnostically, which is to say they should not know whether the source of their data is a specific kind of data source. The controllers should be thin as well, acting basically as a routing layer between the views and models. Controllers take input from the users and perform the relevant actions on the models. The application of this concept varies depending on your target environment -- web, rich client, etc.
The architecture of the model alone is no trivial problem. You have many patterns to choose from and many frameworks, and choosing the right one -- pattern or framework -- will depend entirely on the particulars of your domain, which we have far too few of here to give you more specific advice. Suffice it to say it is recommended you spend some time getting to know a few Object-Relational Mapping frameworks for your particular technology stack (be it Java, .NET, etc.) and the respective patterns they were built on.
Also make yourself familiar with the difference between MVP and MVC -- Martin Fowler's work is essential here.
As for design patterns, the application of most of the standard GOF patterns could easily come into play in some form or another, and it is recommended you spend time in Design Patterns or one of the many introductory texts on the subject. No one here can give specific answers as to how MVC applies to your domain -- that can only be answered by experienced engineers in cooperation with a Product Owner who has the authority to make workflow and UI decisions that will greatly affect such decisions in their particulars.
In short, the very nature of your question suggests you are in need of an experienced OOP architect or senior developer who has done this before. Alternatively give yourself a good deal of time in intensive study before moving forward. The scope of your project encompasses a vast amount of learning that many coders take years to fully grasp. This is not to say your project is doomed -- in fact you may be able to accomplish quite a lot if you choose the right technology stack, framework, etc., and assuming you are reasonably bright and focused on the task at hand. But getting concepts as broad as "MVC" or "OO" right is not something I think can be done on a first try and under time constraints.
EDIT: I just caught your edit re: Zend. Having a framework in place is good, that takes care of a lot of architectural decisions. I'm not familiar with Zend, but I would stick to its defaults. Much more depends here on your ultimate UI delivery -- are you in a RIA environment like Flash or Silverlight, or are you in a strict HTML/JavaScript environment? In either case the controllers should still be thin and operate as routers taking user requests from HTTP gets and posts, and immediately handing off to the models. The views should remain thin as well and make as few decisions as possible. The concept of MVC applied in a web environment has been pretty well established by Rails and the frameworks that followed, and I'm assuming Zend is similar to something like CakePHP in this regard: the application server has a routing system that maps HTTP calls to controller actions that respond with specific views. The request/response cycle is basically this:
User request posted through a URL
Router hands control to a controller class
Controller makes a call to a model with the given params
The model operates on the data, posts back to the controller
The framework maps the finished data into a view, with some kind of code-behind that puts the results of the request in the view's scope.
The framework creates html (or xml or whatever) and posts back to the caller.
It sounds like you want to use MVC and other patterns because they are the new buzz words. Splitting your design among model view and controller should tell you how to spread the functionality of your application. Although I totally agree that using MVC is the correct approach, I suggest you research the pattern and look at some source code that implements it. As a start to your question though, the widgets that will be displayed will be your views, that much should be obvious. Input from the user, such as changing a parameter of some widget or requesting other information will come into your application and should be handled by a controller. A concrete example of this is a Java-based HttpServlet. The controller servlet receives the user request and asks the lower layers of your app (Service, Persistence, etc) for an updated representation of your model. The model includes all of your domain-specific objects (i.e the data from your databases, etc). This data (the updated model) comes back to the controller, which in turn pushes out a new view for the user. Hopefully that is enough to get you started about designing your app.
As further help, you could consider using a framework to assist in the development of your app. I like Spring a lot, and it has a first class MVC implementation that really helps guide you to designing a correct MVC web app.
You may consider using Subject Observer Pattern
Have your class, named DataReader as single Subject. Your multiple widgets will act as Observers. Once your DataReader receives data from server, it (Subject) will inform multiple widgets (Observer).
Your individual widgets may have different presentation to present to same set of data from DataReader.
Update
In the message where subject notify observer, you may include the message type information as well. Widgets will only process message type, which is within their own interest, and ignore rest of the message.
NOTE: This is my new answer based on new the updated question.
Here is a proposed class diagram. I'm going to work on a sequence diagram.
My old answer is here:
Based on the requirements you describe, your model is your database or data warehouse and your views are your pie charts, bar graphs, etc. I don't see the need for a controller, because it sounds like you have a one page dashboard with widgets.
You need to spend your time on the database model. Since you're doing all selects and no updates, go for a de-normalized data model that makes these queries efficient. You should put the results of these queries in a table type object (e.g. 2-dimensional array) or 3-dimensional array based on the amount of dimensions. You are limited to 3 dimensions unless you use animation.