I'm working on some new software, and I'm trying to make it as modular as possible. I have been coding for a while..but I lack some key principles which I am learning as I go along.
In trying to make my current project modular, I am using the model-view-controller architecture. In designing my application, I have found certain things I am unsure of. So I come to you...
I'll give you some information which may be useful:
I am developing this application in Qt.
It is a desktop application.
Single user, so it is not very complicated
My questions are:
When implementing the various modules(models, views etc..) and all
of the classes associated with them, should I be initializing
modules within modules? Should I create a 'model' instance within a
'controller', or should I create everything in 'MAIN' and simply
pass the modules as references?
My strategy is to separate my application into many MVC bundles.
Each one will follow the basic principles: model gets the data, view
displays it, and controller takes care of all interactions between
model-view, and performs all required logic. Is this correct?
I appreciate all of your help.
Thanks.
Should I create a 'model' instance within a 'controller', or should I create everything in 'MAIN' and simply pass the modules as references?
Pass the modules as references. I don't know if Qt has the concept of packages within a bundle, but in Java, I have separate packages for the model and the view.
My strategy is to separate my application into many MVC bundles. Each one will follow the basic principles: model gets the data, view displays it, and controller takes care of all interactions between model-view, and performs all required logic. Is this correct?
Yes, that's correct MVC principles.
Sometimes in a more complicated application, your application view might consist of the GUI (a view) and a model of the GUI (a model). In this case, the application model, which is probably a database access model, interacts with the GUI model. The controller for both the GUI and the application is driven by the actions of the user.
Related
I'm creating a web app using an MVC framework. I thought of adding a layer between the controller and the domain models, I think it's called application layer in DDD, to avoid putting logic that is specific to a certain use case in the domain models.
The controller will only interact with this layer and this layer will orchestrate the operation using the domain models. This layer will be kept as thin as possible pushing all the logic that is not use case specific to the domain model.
I will call the classes that belong to this layer DomainCtrl.
Example login scenario:
Model: LoginForm
DomainCtrl: AuthCtrl
UI: ui controller
1.ui controller receives request
2.creates instance of AuthCtrl
3.AuthCtrl creates instance of a LoginForm and fill it with request data passed to authCtrl
4.LoginForm performs the login
5.authCtrl does other things that are specific to this specific way of login -> returns errors to ui controller
Is this a good way to organize an app?
Your question
Is this a good way to structure an app
is a very loaded question. The simple answer is Yes, but the more correct answer is It depends.
Let's start with the simple answer. Having your main application be unaware of the UI is generally a good idea. It means that you can easily consume your application from various places. In DDD this outer layer is usually called Application Layer. It is mainly responsible for orchestrating interactions between your domain, persistence and other resources that you might rely on. This also allows you to have your domain at the center unaware of everything else. This makes your domain easily testable and maintainable if implemented well.
Now the "it depends" part of the answer. DDD is not the only successful way to build an application, and in some cases it might be more of a hinderance than anything else. You have to ask yourself what is my app doing. Are there many domain specific rules? Am I only fetching and storing basic data etc? These are all questions you need to answer before you choose an architecture and technologies.
I would still say you probably won't go wrong by choosing the DDD approach as it is generally a good way to do things.
*Note: Your example is not that clear to me but you should be careful of spilling UI concepts into your domain/application. A login form is completely a UI concept as is auth to a certain extent. You can probably have your application return the details of your user, but the UI layer should decide if the user is allowed to proceed or not.
At a high level view, Yes
But it ultimately depends on "how" you logically separate your layers. In your scenario, I don't see any application layer.
I assume AuthCtrl is the domain? Who creates AuthCtrl? what layer does it exists?
The project I am working with uses JSF + Spring + Hibernate.
This is a design question that I have often been confused about.
I currently inherited a project that contains a dao -> service -> view -> controller "layered" approach.
The "Controller" layer / tier? currently has all logic and objects that interact with the front end. I have been told that it is good practice to separate this into two layers/tiers, where the "Controller" layer/tier only contains methods/objects that interact with the front end and a second layer (bm?) that contains all business logic used by the controller.
1st.) What would the purpose be of dividing up the controller in such a way?
2nd.) Is there anything wrong with leaving it the way it currently is?
1st.) What would the purpose be of dividing up the controller in such a way?
You must handle the business logic in Service Layer. Benefits of separating the business entities from Controller/UI Layer :
You can reuse the business entities with another client sections. Example : if you are developing a web based application as UI, later you also developed a Desktop UI. In this case you can reuse your Business Layer operations with multiple UIs. You can also use business layer to work as a web service.
Decoupled business operations are easier to manage. If someone from development team has no idea how UI code works and only wants to correct some business logic, he can does.
2nd.) Is there anything wrong with leaving it the way it currently is?
If you are new to Layered Architecture it will take some time to understand and implement the desired layers. It depends on time frame and application requirements. If you are planning to use the above points in your application go with layered architecture otherwise go with current implementation.
If you're asking why it's a good idea to have a service layer that's used by the view, then the answer is that more often than not you want to access services from parts of the application that are different from a specific view.
For instance, suppose you had logic to validate an order, which at first was primarily used on some /order.xhtml page. It wouldn't hurt that page to have the Service and corresponding objects (say Order) right there in the view.
But then the requirement comes to do order validation from a batch job. If the code for that validation is tightly coupled to your view, this will be impossible or very hard and most likely be very awkward (I've seen people mocking a JSP PageContext since some business logic happened to require it).
There are quite some other situations where this creeps up, like e.g. an external API via JAX-RS, a totally different view (page for another user, or perhaps a mobile targeted UI), etc.
Business logic layer should not be implemented on the service layer.
DAO/Service Layer -> Business Logic Layer -> UI Controllers
-rico
I want to make one mvc3 application which is student management.
I've seen some open source projects.
They have used solution structure like core,data serve rice.
is there any reason to use structure like this?
Usually it is a good a good idea to keep things separated.
By that I mean not mixing up business logic with database management code and having non-UI code in the view files.
This makes it a lot easier for others to understand the code you have written. I also helps you, when you get back to some project after some time to make improvements or correct errors.
I hope this answered your question, if not shot again.
Edit: I found this link explaining how it is done in the MVC framework.
Use layered architecture where you isolate each layer by using the Separated Interface pattern. For the database, use Repository pattern (easiest way to archive that is to use a ORM like nhibernate).
Use an inversion of control container to reduce coupling (with the help of interfaces) and make it easier to handle dependencies between classes.
As stated in the previous answers, you should separate your logical tiers into a minimum of BusinessLogic (Entities,validation,etc..), Data(your favorite ORM), and presentation (MVC).
However, if you are just starting out it may be a little daunting to incorporate all of the more advanced concepts of a SOLID architecture.
Separating logical tiers doesn't always have to mean separate projects. The standard MVC3 template demonstrates this with the "Models" folder. Any entity added to this will be under the namespace Myproject.Models. Later you could re-factor the code in the Models folder into a separate dll,add a reference, and as long as the namespace was still Myproject.Models the MVC app will continue to work.
The same thing could be done for your Data Access layer!
If you're just starting out I would recommend developing your app in the MVC project and separating your DAL and Business Layers with a Folder (Namespace). Once your application is working you can re-factor as needed.
What are some lesser known tips for implementing a loosely-coupled MVC structure in a non-trivial desktop application (e.g. having at least two levels of views/controllers and more than one model)?
Use interfaces.
A lot. I like using the "IDoThisForYou" style (even in a language where this isn't idiomatic) because an interface represents a role that another class can use.
Make the controllers responsible for controlling interaction
The controllers control interaction between domain objects, services, etc.
Use events to pass information between controllers
Let every controller who needs information subscribe to the event. Use an interface.
Don't put presentation information on your domain objects
Instead, allow the controller to create a presenter or view model which has the information you need. This includes no "ToString()". If you're in a language without multiple inheritance you might end up with a bit of duplication between presenters. That's OK - duplication is better than coupling, and the UI changes a lot anyway.
Don't put logic in your gui
Instead, allow the controller to create a presenter or view mdoel which has the information you need. This includes train wrecks like "MyAnimal.Species.Name" - make it present "SpeciesName" instead.
Test it
Manually. There is no substitute. Unit and acceptance testing goes a long way, but there's nothing like bringing the app up and actually using the mess you wrote for finding out how messy it is. Don't pass it to the QAs without having a go yourself.
Oh, and don't mock out domain objects in unit tests. It's not worth it. Use a builder.
Declare event handlers in your interfaces (important for the views). This way you can loosely couple event handling which is managed by the controller. You may need to use the InvokeRequired when working with the view if your application is multi-threaded.
In MVC, do controllers belong with an application, or can they go into a shared library? For example:
//this is a shared library
LibShared
//these are two apps
appA ->LibShared
appB ->LibShared
Shouldn't each app implement its own MVC and use any shared libraries as perhaps part of the app's logical model or simply another library reference (utilities)?
Also, is there ever a situation in which an MVC Controller is stuck in a shared library? I thought Controllers needed specific views located in a specific app. Meaning, the Controller must go in that app?
Or can Controllers be generic (i.e. shared library)? Doesn't that mean they are no longer Controllers?
I would advise that you should only be separating out your controllers into their own module/package/library (herein referred to as modules) if you have a requirement to do so (i.e. immediate re-use). If no such requirement exists at present then I would defer the decision to when it is required, it sounds in your case you are about to unnecessarily over-engineer. It should in theory be possible to refactor later to a separate modules without much hindrance, however be careful regarding coupling, separating out to different modules doesn't reduce the coupling, look carefully at your dependencies at how much the controller is orientated to one style of view.
one liners answers to your question to your application is
YES, YOU CAN MOVE YOUR CONTROLLER TO A SEPARATE LIBRARY WITHOUT A SINGLE LINE CODE CHANGES.
I suppose any code can go anywhere, what would drive us to put something in a shared library or keep it with the app?
I would consider two things:
1). What's the rate of change? When we change the app overall is this likely to change.
2). Could anything else need to use it? If so when I realease a new version would the other client immediately
Typically a controller would be strongly associated with the application and hence not of much interest to any other app, and it's probably fundamental to the app changing as the app changes. Hence packaging with the app makes sense.
Now if the conroller is somehow more generic, perhaps configuration driven then shared library makes sense.
Controllers does not necessarily needs to be even in the same operating system. You could have a view in Windows, a Controller in Unix and your Model in a Sparc. Remember MVC is just a pattern, a way you could do something which is more robust and easier to modify.
Your controller could be a shared library. Does your controller should be aware of your views? Not necessarily. That depends on how you handle the communication between modules. On a good MVC implementation, modules simply interchange messages or events. So, a View send an event to the Controller, the Controller decides what to do and send a message back. The response of the controller could be something like "Show Window X". Be advised that "Window X" could be interpret by the View module, if the View is an a Web module, then the View just put the proper aspx page. If you have another view who happens to be a web application the renders Form X.
At least in CakePHP and in the architecture that Mike McShaffry explains in his Game Coding Complete book the controller does belong to the application.
However, in both cases the architecture is such that the application inherits the basic functionality of a model, view, and a controller from the framework.
Eg.:
// "super" controller of all applications using this framework
class Controller
// uses basic libraries that allows the inheriting applications to work minimally
class AppController extends Controller
// mainly uses the parent class's methods but can also substitute to using
// additional libraries
By framework here I mean the system that encapsulates the use of libraries. In CakePHP this encapsulation in turn is done by using libraries in the respecting models, views, and controllers. So neither of those components is free from attachment to libraries.
In Mike McShaffry's architecture however, only the controllers and views use libraries. So the models are left uncoupled and are thus highly portable to different applications.