I have been using for a while but still I am confuse on what to include in my controllers specifically "When should I use Model and When to Use Service"?
I am confused if I am making the right thing.
I would suggest to never use models directly into the controllers.. Adopt the repository-pattern which enables the use of dependency injection of services into the controller.. Use Service Layer to contain the business logic.. In this way all the related codes would be onto similar layer.
Reference for repository pattern:
http://heera.it/laravel-repository-pattern#.VuJcVfl97cs
Please don't use model directly in your controller, unless if you are building a very simple application but for a large application, it would be good to use a repository. Kindly take a look at this tutorial https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/
Related
I do have ready the topics in the documentation, but please help me to know why this is the most correct way and what's wrong (and not enough) with methods like $this->load->model('User_model') or setting the /config/autoload.php configs in CodeIgniter?
In case we want to use additional controllers (like Request $request) as method injection, or UserRepository $users as contrustor injection (which is not a meaningful example in my opinion, but has be exampled in the main documentation) what's wrong with accessing those classes as properties (like $this->input->get('id')) or traits if we want to be committed to OOP concepts?
It more seems to be just coding style and framework conventions (which is of course important, too), isn't it?
I'm using AutoMappper 5.2 in my MVC project. I have made use of IMapper creating profiles which I understand profiles are a way to organise mappings. I am injecting IMapper into my controllers using Simple Injector to register an instance.
What I would like to know is can you use them in a way where you only retrieve/set up the profile you need for a specific controller? If so, how would you go about that? If you have to add all the profiles into one mapping configuration object does that have a performance impact or is it marginal?
I cannot find any resources or questions that deals with using a specific type of profile, they only deal with creating and registering them.
I think my answer to a similar question might help you. It is the last answer here: How to register AutoMapper 4.2.0 with Simple Injector.
It's basically what Steven said.. you need to create a generic profile wrapper that implements the IMapper interface, with the generic argument being a specific profile. This allows you to create any number of profiles, batch-register them all, and to inject only the one that you need in your controller:
ProfileMapper<ApplicationProfile> appProfileMapper;
ProfileMapper<MvcProfile> mvcProfileMapper;
ProfileMapper<GuestProfile> guestProfile;
I'm trying to understand where Spring custom namespace can help -- like simplifying somethings in a large application.
The last comment on this blog was intriguing:
I'm building out a namespace at work for making service and bean management more standardized within the development group. This also tends to make things simpler and not have them worry if I change the standard for a bean definition or maybe use different factories for different types of services in the future. I'm still figuring out how to best utilize this new mechanism, though.
Trying to understand how custom namespace helps in bean management.
If you developed custom namespaces, could you please post how custom namespaces helped in your development.
This blog has a great post about using custom namespaces and gives you a few examples as well.
Check this github repo for a working example of spring's custom namespace handling.
Or this article on spring io.
I am using MVC3 for my application and I have a question about validation. I have a Business Logic layer that is separate from my web layer where I will have a function like CreateUser, which creates a new user for the application to use. I want this function to be accessible in two places: 1) Somewhere in a controller that makes use of it and 2) in a "Setup Data" program that inserts data into the system.
I want to make use of things like ModelState.IsValid to check for all basic validation, but this won't help me for my Setup Data mode (or any other mode that doesn't go through MVC). Is there any way I can still leverage this code, but to contain all validation in my BusinessLogic layer instead of in the controller without having the BusinessLogic layer rely on MVC?
Thanks.
It looks like this article about Service Layers has what I need. Other suggestions are still welcome. Thanks.
Note that the article on service layers still means that you need a dependency on the MVC assembly. After wrestling a bit with this myself recently, I'm now of the opinion that keeping things as separate as possible is a good design. In my model assembly, I have a services folder wherein from, say, a Create() routine, I validate and throw custom exceptions.
The service layer doesn't care who or how these exceptions are consumed. In your MVC app, map them into model state errors collections or whatever. Your design is all the more solid because your model assembly doesn't depend on some validation runner making appropriate use of MVC validation attributes, collections, etc.
I also noticed the article mentions a repository. I know it's all the rage these days but if you're already using an ORM like Entity Framework, a repository is really just a DAO. Reposity is the new Singleton.
How would one typically implement a service layer in an MVC architecture? Is it one object that serves all requests to underlying business objects? Or is more like an object that serves different service objects that in their turn interact with business objects?
So:
Controller -> Service -> getUserById(), or:
Controller -> ServiceManager -> getUserService() -> getUserById()
Also, if the latter is more appropriate, would you configure this ServiceManager object in a bootstrap? In other words, register the different services that you will be needing for your app to the service manager in a bootstrap?
If none of the above is appropriate, what would help me get a better understanding of how a service layer should be implemented?
Thank you in advance.
The way I read this question, there's really two things that should be answered:
A) I would prefer splitting "Service" into "CustomerService" and "OrderService", in other words grouped by domain concepts.
B) Secondly I'd use dependency injection to get the proper service directly where I need it, so I'm basically using alt 1. The added abstraction in alternative 2 provides no additional value for me, since the IoC container does the important part.
Using a "facade" is one way to go:
"A facade is an object that provides a simplified interface to a larger body of code"
I personally prefer #2, and yes, it would generally be configured in a bootstrap, or the dependencies would be resolved using some sort of IoC container to give you the actual concrete instances.
I would also like to comment, and yes I understand this is probably more of a personal preference. Try to avoid using the name "Service" layer for these objects. refer to them as repositories or something else. if you use service, that term becomes overloaded ... because then devs are like, "do you mean like, a rest or wcf service?". trust me, we did that with a recent project, and we confuse ourselves all the time when we're talking about where to make code changes :-P