I'd like to use a Cakephp 3 component inside a class located in, for example, /src/Classes/Customers.php.
I don't know how to instanciate the compoent.
You are not supposed to do that, components are services for the controller layer, and that's where the story ends. It is strongly advised that you do not use framework components outside of their intended purpose, this will just cause trouble at some point!
If you want to share logic between components and other utilities unrelated to controllers, then you should put that logic into for example generic service classes that both your components as well as your other code can utilize.
Related
I am new to coding and I was wondering what is the logical way of representing the interconnections between classes of a system, more specifically the GUI class and the system's classes. Let's consider an online ordering system. In addition, let's consider that we need to make an order in this system. So I imagine that there is a GUI ( after logging in ) and there is a button for make order. So this means that the GUI class will be connected directly to the make order class ( if we assume that there is a class that is responsible for making orders )? Or there should be some intermediate class that should be connected to the GUI and controls the logic of the system ( if user choices make order then this control class deals with the make order class, if user choices to track order then this class deals with the track order class and so on )? I am looking for the most efficient way of writing code.
Edit: In many textbooks, they mention three types of classes that deal with this issue which are boundary class ( GUI), controller class and Logical class, but actually I don't know the exact meaning of the controller and the logical classes types.
MVC is one famous pattern used for this specific purpose. MVC stands for model view controller.
View = Classes responsible for the UI.
Model = This is the business domain where all complex business logic lives. OOP is heavily used here.
Controller = This connects the view with the model. Example - a click on the UI needs to be fulfilled by a model and the controller will connect the UI to that model.
Add REST to this mix which will help UI communicate with Model and the make the model agnostic to type of clients being Web, Mobile or even another server. Angular, React etc are heavily used for UI presentation.
You would needs a persistent layer to persist the state of the model and read it back. Example - A database which can save historical order and read them back. JPA and Hibernate are famous tools for this.
You don't need to deal this raw MVC, rather use one of many web frameworks which will take care of boiler plate code for you. Spring MVC is one such framework in Java world. There are equally famous frameworks for python, node, scala etc. This framework will have standard ways to do REST, Persistence, controller etc. So start from this.
I can't seem to grasp the modules of dagger.
Should I create a new instance of a module each time I want to inject stuff?
Should I create only one instance of a module? If so where should I do it?
Is there a more complex example of fragments and activities used with dagger?
Thanks
You should think more about #Component than #Module. Modules just create objects that need further initialization. The actual work happens in Components, which modules are part of.
Should I create a new instance of a module each time I want to inject stuff?
You should create your module when you create the Component it is part of, since only this component is going to need it. If you find yourself creating the same module multiple times, you are most likely doing something wrong.
A module uses additional arguments (pass them in via the constructor) to create more complex objects. So if you were to have e.g. a UserModule you'd pass in the a user to create user dependent objects from the resulting component. If the user changes lose the old component and create a new module and a new component—the old objects should not be used anymore.
Keep the component where / when appropriate and be sure to use Scopes, since they determine the lifetime of your component.
Should I create only one instance of a module? If so where should I do it?
You most likely will just create a single instance of #Singleton annotated Components and Modules. In android you'd most likely keep the reference to the component (not the module!) in the Application or some real 'singleton'.
Is there a more complex example of fragments and activities used with dagger?
Try googling. There are lots of high quality tutorials with linked github repositories that go into much more depth and detail as would be possible here on SO. e.g. see Tasting dagger 2 on android.
I'm building a WPF application using MVVM pattern, and Caliburn.Micro is the framework choice to boost up the development.
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer to handle logic for specific business cases. VM is left with data binding and simple conversion/presentation logic. Below BL is an extra Data Access layer (DAL) that encapsulates the Data model (DM) underneath built with Entity Framework.
I'm pretty new to both WPF, MVVM and, of course, know almost nothing about Caliburn. I have read plenty of questions and answers about the Caliburn usage and now trying to use what I've learnt so far in my application.
My questions are:
Does it sound okay with the above layered architecture?
In the application bootstrapper, is it correct that we can register all services that will later be used (like EventAgreggator (EA), WindowManager or extra security and validation services), and also all the concerned VMs? These should be injected into VM instances via constructors or so (supposed I'll be using SimpleContainer). So from any VM that are properly designed and instantiated, we can have these services ready to be used. If I understand correctly, Caliburn and its IoC maintain a kind of global state so that different VMs can use and share it.
Navigation: I know this topic has been discussed so many times. But just to be sure I'm doing the right way: There'd be a ShellViewModel acting as the main window for the whole application with different VMs (or screens) loaded dynamically. Each VM can inherit either Screen or ViewModelBase or NotifyChangedBase. When I'm in, let's say, VM A and want to switch to VM B. I'd from inside VM A send a message (using EA) to the ShellViewModel, saying that I want to change to B. ShellViewModel receives the message and reloads its CurrentViewModel property. What should be a proper data structure to maintain the list of VMs to be loaded? How can stuffs like Conductor or WindowManger come into the place?
Can/Should Caliburn in one way or another support the access to the database (via EF). Or this access should be exposed to VM and/or BL only?
Thanks a lot!
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer
That's the standard case. ViewModels can't/shouldn't contain business logic which is considered to be part of the Model (Model in MVVM is considered a layer, not an object or data structure) in the MVVM. ViewModel is for presentation logic only.
Yes, as long as your Business (Domain) Layer has no dependency on the DAL (no reference to it's assembly). Repository interfaces should be defined in the Business Layer, their implementations in the Data Access Layer.
Yes, Bootstrapper is where you build your object graph (configuration the IoC container).
Registering ViewModels: Depends on IoC framework. Some frameworks let you resolve unregistered types, as long as they are not abstract or interfaces (i.e. Unity). Not sure about Caliburn, haven't used it. If the IoC supports it, you don't need to register them.
One possible way to do it. I prefer navigation services though, works better for passing around parameters to views and windows that are not yet instantiated and you always know there is exactly one objects handling it.
With messages, there could be 0, 1 or many objects listening to it. Up to you
What do you mean with support access to the database? You can use it to inject your repositories and/or services into your ViewModels, other than that there isn't much DB related stuff to it.
What I am trying to do is inject a component into my MVC app and make use of it from the controllers.
Currently I am not trying to use MEF for the actual controllers, but i want to import components e.g. A loggin component into the MVC app.
Where is the best place to do this?
Currently I have, directly in the controller, put my compose parts code and ILogger property, but I get the feeling this is not the best way. Seems like I should only need to call Compose once in the application.
So should it be in the global asax file that I do the compose?
If so, how do I get a handle on ILogger from my controllers? Should I have a "base" controller, where i inject ILogger into the constructor and inherit every standard controller from?
Hope that makes sense - I'm just struggling a bit with the structure of my code.
Thx
I use Log4Net and inject the logger into each controller. I dont think its a big hit when you use injection. Take a look at Ninject. It has both an MVC implementation and a logging module. The modules are loaded once in the global, then it injects the controllers. Basic DI, but do you really need more? If you create a base controller you will still have to create a ctor in each controller that can be injected.
You might create a base controller with the logging, then use property injection. I have never done this, but if all controllers use the same base it should work fine.
I am building a site in ASP.NET 4 and MVC2 that will have premium features, such as SMS notifications that will only be available to paid subscribers. I also have additional modules for things like Inventory, and Transactions etc
I am already leveraging the standard MembershipProvider, and am leaning towards using Roles tp provide this functionality.
ie: have an "SMSModule" role that the user gets if they pay for the add-on SMS service
This makes the controllers simple with a little attribute decoration, but the problem I see with this is that there will be a bunch of conditional code scattered through my views etc
Is there a better method of providing a "module" style approach in .NET 4 and MVC2???
You can add your conditional logic to view models, use the controllers to set the viewmodels appropriately and it should be fine... Sometimes you have to have the if statements inside the views even if not so ellegent. Unless of course you are using a view engine like spark then your if statements are placed in another unobtrusive location, but they still exist! You can always create HtmlHelpers and set the code to the serverside and based on the logic display appropriately...
FWIW I ended up using a combination of Descriptors in Spark View Engine, along with a custom Feature provider and associated ActionFilter