I would like to log communications activity and, as part of logging, display communications history in a window on the screen. I don't want the communications modules to know about the screen of course, but any method can write to the log. The logging module then routes the information as appropriate (screen, file). Is logging considered part of the model?
Whether the commands, that are executed by instance, are logged or not should not affect the instance itself. Which means that if, for example, you want to log operation performed by controller, the controller itself should not be doing the logging or in any other way be aware that it gets logged.
The much better option is to have the instance decorated. The decorator would require the original instance and a logger injected thought constructor.
Assuming that your MVC components (views, controller and structures from mode layer) are already created via factory, this would be the best "level" at which you switch between logged and unlogged mode.
TL;DR
No. Logging is not part of MVC triad itself.
Related
In my Grails app, I am using methods in a service to do complicated validation for user submitted data. Unfortunately, Grails is quietly sabotaging me.
I populate the domain instance with the user submitted data
I hand the instance off to the service, which analyzes the properties.
If errors are found I add them using
instance.errors.rejectValue('myValue','errors.customErrorCode','Error')
BEHIND THE SCENES, when the service passes the domain instance back to the controller grails checks for changed properties and calls validate() before returning the instance. (verifiable by seeing the beforeValidate event called on returning a domain instance from a service to a controller where one or more properties has changed)
That behavior clears any custom errors I have added and the instance I get back in the controller is now incorrectly without error.
How can I
A) stop grails from validating between service and controller
OR
B) prevent a validate() call from wiping my custom errors.
EDIT
So far I've found one partial answer,
If you use instance.get(params.id), grails will self validate behind the scenes wiping custom errors.
If you use instance.read(params.id) you can bypass this behavior to an extent.docs
But this solution is limited by domain relationships. Any other solutions welcome.
Seems that it is not custom validation. It can be because of transactional service. Service opens separate transaction for each method and clears entities after method end. You can find this mentioned in docs(read the last paragraph of part ). So errors dessappear not because of validation.
Don't know if your service is transactional. But if it is - you can add #NotTransactional annotation to method were you want not to loose errors. And
errors will be saved.
Hope it helped,
Matvei.
Not sure how your code looks like or what is causing the problem, but in any case I strongly suggest implementing custom validators in the domain class or in a command object within the constrains.
Here are some examples from grails docs:
http://docs.grails.org/2.4.0/ref/Constraints/validator.html
I'm still in a learning phase with PHP and Laravel 5 and since I upgraded to L5, I struggle with where my code belongs to. There are so many files and folders which seem to have the same purpose or at least are very similar. There are Commands, Controllers, Events, Services, Requests, etc. I give an example with my workflow and where I would place the code and I hope you guys can comment on that and correct/help me.
Situation
I want to register a new user in my application and send a welcome e-mail when he registered successfully.
Workflow
Controller (UserController): Returns requested view (register).
Request (RegisterRequest): The "RegisterRequest" validates the entered data.
Controller (UserController): Passes the validated data to the "UserRegistrar" (service) in 'App/Services'.
Service (UserRegistrar): Creates a new user and saves it to the database.
Controller (UserController): Fires the "UserWasRegistered" Event.
Event (UserWasRegistered): This Event call the "SendWelcomeEmail" Command.
Command (SendWelcomeEmail): This Command will send/queue the welcome e-mail.
Controller (UserController): Redirects the user to a view with the information that he has been registerd successfully and a message has been send to him.
Logic
Okay, let's discuss some logic:
Controller:
Doesn't hold much code.
Mainly there to return views (with requested data).
Handles workflow and "connects" modules (Services, Requests, Events).
Request: Validates the data for a specified request
Service: A service "does" something. For example it's doing requests to the database.
Event: An Event is a central place to call one or more tasks if it is fired (SendConfirmationMail, SendWelcomeMail).
Command: Mainly there to handle the logic for ONE certain task. For example sending a confirmation mail. Another command will hold the logic for sending the welcome mail. Both commands are called in the Event described before.
Repositories: What is that?!
So this is what I understand. Please help me and feed me with information.
Thanks,
LuMa
Your question is a little vague and will likely attract downvotes as being "too broad". That said, here's my take on this...
The biggest issue I see is that your application structure is very different from the recommended L5 structure - or even the standard MVC structure - that it's no wonder you're getting confused.
Let's talk about your "Logic" section:
controller - you're on the right track here. The controller is the glue between your models and your views. It can do some processing, but most should be offloaded to classes that handle specific tasks.
request - what is this? L5 includes a Request class that includes methods for examining the HTTP request received from the client. Are you talking about subclassing that? Why? If your idea of a "request" class is primarily concerned with examining input, you can either do that in your model (ie. validating stuff before sticking it in the database) or in your controller (see the L5 docs on controller validation)
service - again, what is this? You talk about "doing requests to the database", but L5 provides a class for that (DB). At a higher level, database access should primarily be done through models, which abstract away most of the low level database access. As for other services, what I usually do is create libraries to perform specific processing. For example, my application has a particular third party project management application that it accesses via an API. I have a library for that, with methods such as getProject or createProject.
event - An event is a way of ensuring that some code is called when the event happens, without a whole lot of messing about. It sounds like you have the right idea about events.
command - again, it sounds like you have the basic idea about commands.
repositories - these are way of abstracting the connection between a resource (primarily the database, but it can apply to other resources too) and the code that uses the resource. This gives a way to switch the underlying resource more easily if you (for example) decide to change database servers in the future. They are optional.
You also haven't mentioned anything about models. L5 provides an excellent way to deal with your data in understandable chunks via Eloquent models - this will make your life much easier.
My suggestion is this: start small. Build a simple MVC application with L5 - A model (to save some data), a view (to display the data), and a controller (to put the model & view together by handling the client request). Once you have that, start extending it.
There are tutorials out there that will give you this basic structure for Laravel - most are for Laravel 4, but see if you can follow the basic ideas and build something similar for Laravel 5.
In the _Layout.cshtml, the #Html.MvcSiteMap().Menu("viewname") caused extra 2s in each request. I found that the repository's constructor being executed several times depends on the menu's count so I guess this might be where the extra 2 seconds cames from.
Is there a way to prevent the constructors be executed once the menu rendered?
I suspect the reason for this is because you are using Security Trimming. In order to determine whether each link has access, MVCSiteMapProvider creates and releases an instance of each controller for each action. The only way to avoid this is to disable security trimming.
With security trimming enabled, it is not recommended to have any heavy processing within your constructors, as this will negatively affect performance. You should defer any processing (such as opening database connections) to later on in the request lifecycle by using an Abstract Factory to create the connection and injecting the factory into your constructor instead of the dbcontext/connection object. See this post for an example.
That said, the AuthorizeAttributeAclModule is not as efficient as it could be because when you have controllers with a lot of action methods, the same controller instance could be reused instead of creating one for each action method. You could make a custom AuthorizeAttributeAclModule and use the HttpContext.Items dictionary to request-cache each controller so they are reused instead of re-instatiated. You will need to do some refactoring to do it, though. The controller is created on line 235 and it is released on line 108. You need to make sure that the release isn't called until the after very last node is checked. You can do this by creating an IActionFilter to release them after the action is complete, but it means that action method will need to know about the same request cache (in HttpContext.Items) as the AuthorizeAttributeAclModule. You just need to implement the OnActionExecuted method to clean up the controllers from the request cache.
In MVC and most other service frameworks I tried, caching is done via attribute/filter, either on the controller/action or request, and can be controlled through caching profile in config file. It seems offer more flexibility and also leave the core service code cleaner.
But ServiceStack has it inside the service. Are there any reason why it's done this way?
Can I add a CacheFilterAttribute, but delegate to service instead?
ToOptimizedResultUsingCache(base.Cache,cacheKey,()=> {
// Delegate to Request/Service being decorated?
});
I searched around but couldn't find an answer. Granted, it probably won't make much difference because the ServiceStack caching via delegate method is quite clean. And you seldom change caching strategy on the fly in real world. So this is mostly out of curiosity. Thanks.
Because the caching pattern involves, checking first to see if it is cached, if not to then execute the service, populate the cache, then return the result.
A Request Filter doesn't allow you to execute the service and a Response Filter means that the Service will always execute (i.e. mitigating the usefulness of the Cache), so the alternative would require a Request + Response filter combination where the logic would be split into 2 disjointed parts. Having it inside the Service, lets you see and reason about how it works and what exactly is going on, it also allows full access to calculate the uniqueHashKey used and exactly what and when (or even if) to Cache, which is harder to control with a generic black-box caching solution.
Although we are open to 'baking-in' built-in generic caching solutions (either via an attribute or ServiceRunner / base class). Add a feature request if you'd like to see this, specifying the preferred functionality/use-case (e.g. cache based on Time / Validity / Cache against user-defined Aggregate root / etc).
I made a settings page for my website. On this page the user is presented with a bunch of site wide settings they can manipulate. I made it so when the user selects a setting the page will automatically run an ajax request to send the setting to the database. My question is in how I do this.
At first I just did calls to the repository. One call to get the data back, put it into a ViewModel then give that ViewModel to the View and the ajax controller just sent the settings back to the database. This way seemed like the best at first especially for unit testing purposes since I could just pass in a fake repository if needed. Then for the user to get a setting they just called the repository and pass in the setting name they want.
Then I had a bright idea. I made a singleton class called SiteWideSettings and each possible setting on the site was a property of the site. When SiteSettings is called for the first time all of the settings are loaded. When Set is called on any of the properties it will call the repository function to send the setting. Now with my Settings view I'm just passing in SiteWideViewOptions.Current and on the ajax call I'm updating the property that was changed. This is working for me however it's not very unit testable since I can't really pass in a repository to a singleton's constructor since its constructor is private. What I currently have is working fine but I just don't feel like it's the best solution and unit testing isn't really possible here.
I'm thinking of one of the following but not sure which is the best.
Add a Repository property to the SiteWideSettings class
Add a function to the SiteWideSettings class to pass in a repository
Not use a singleton for this at all and just go back to what I was doing before I had this idea
Any comment on this would be greatly appreciated.
Note: I know. I know I'm doing unit testing wrong in this case because I didn't write my test first so please don't scold me for that.. I have already scolded myself and with my next task I won't do it again I promise :)
"Then I had a bright idea. I made a singleton class called
SiteWideSettings and..."
This sounds like a bad idea. Let your database be ground-truth for what the settings are, not some in-memory cache that you now need to keep up to date. Let your ORM do caching if you need it for performance otherwise you are just adding problems especially if you now try to run your site on more than one server.
If you want to simplify the controller so it has less 'set-up' and 'tear-down' code in it, use an IOC (e.g. Autofac) and inject any dependencies you need (e.g. a DataContext or a Repository) on a per-http-request basis.
Your action methods are now easier to test since you can simply instantiate your controller (injecting the dependencies manually using its constructor) and then call your method.