Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
My MVC's controller actions are getting huge. I want to create a service layer so that I can move code there. The idea is to use the SOLID principle: the controllers use the service layer to get the domain models that will be then transformed into view models.
My question is simple: Should my service layer be a new assembly (project) that will go along with my MVC project or should it be simply a class inside my already existing assembly (MVC Project)?
My approach will be similar to the following one, but unfortunately the post doesn't explain exactly how was the service layer defined:
http://weblogs.asp.net/gunnarpeipman/archive/2011/06/20/asp-net-mvc-moving-code-from-controller-action-to-service-layer.aspx
I would consider making the service layer a separate thing.
Service can be an interface-based object that is implemented either in-memory in the application or distributed and accessed remotely via SOAP, REST, RCP-XML, or anything else. The controller/client need not know or care if they have a client program that's interface based as well.
A dependency injection, interface based solution would allow you to inject client and service implementations in pairs so controllers need not be disturbed if you change how to access the services.
Controller is usually closely tied to a view. Views come and go, but services tend to remain. Services should map to business functionality that could be shared across applications.
Should my service layer be a new assembly (project)
Yes, it should. Other UIs might want to use it in the future...
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
At my job we use Entity Framework for data access. I am creating a Data Access Layer, a Business Access Layer and a few different types of projects to access the BLL (webAPI for client applications to interface with, multiple MVC websites and a few different desktop WinForm applications).
I added the DTOs to a separate project named "DTO". The goal of this project within this solution is to have a DLL with all the definitions for the classes and interfaces that will be past back and forth. That way this one project can be created as a git submodule within other solutions and updated for all the UI projects to use collectively. I will not be working on all the UIs as we bring more developers into the project and we will probably need to have multiple VS solutions.
My thought was to have the Data Access Layer pass back and take in DTOs instead of entity objects. This would decouple the process completely.
If we ever wanted to replace the DAL with something else as long it followed the interfaces defined in the DTO project we should be fine. I also think it would make testing easier as I can replace the DAL with a project to generate the DTOs with something like Seed.net. BTW replacement is a real possibility given our environment.
Is adding this layer of complexity bad or against design standards? Is there something I am missing?
This is the way I work, and having worked in the Cloud world for some years now, it seems to be the way everyone works.
Typically you have the following Projects (each build to an individual Assembly)
- REST controllers
- Models
that are used to pass information between Controller layer and Business Logic
- Business Logic Interfaces (like ImyService)
- Business Logic (like myService)
- DTOs
- IRepository (like ImyRepo)
- Repository (like myRepo)
--> this is the same as DAL.
The great thing with doing this is that if you add Dependency Inversion (IoC) then you can make a mock Repo, in order to isolate and test the Service (Business Logic) layer and so on by injecting it into NUnit unit tests.
Quite often people in the industry (including me) use AutoMapper to convert Models to DTOs to Entities and the reverse.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm writing a web api app that I have divided into various projects such Web, Services, DataAccess - so basically the web api controller contacts the service layers which then can access the data access layer.
I was returning just a bool to let me know if the data access method has completed ok, then picking this up in the service layer and then back to the controller...where I can then respond with a HTTPStatusCode of 200, or 500 etc..depending whether or not the operation has returned a true or false.
Instead of bool is it good practice to use HttpStatusCodes instead...or should HTTP status codes only be used in the Controller - to return a response to the app that's calling the web api or should it be something else?
Thanks,
First of all classes should have the least possible knowledge of the world around them. Suppose you implement the repository pattern to fetch data. Your repository (data access layer) should not even know about HTTP, nor it should expect to be a part of web application. Its only concern is accessing a particular table.
It’s difficult to suggest specific solution without understanding the big picture, but you may consider the following:
Raise an exception if your application depends on data that couldn’t be fetched. It’ll propagate as 500 response.
Use enum instead of bool to make code more readable.
Create DataResponse class to incapsulate result of data access operation. You may then use the adapter pattern to adapt DataResponse to HttpResponse.
Vague question, but I'll attempt an answer.
This really depends on the reason for separation between the layers, and what each layer is concerned with. One question I would ask myself is why do you have a Service layer? Is it because it contains the business logic? Is it because intent is to have an option to reuse it outside WebAPI context? Or do you expect Service layer to have dependency on WebAPI context (i.e. that it is a web request, and not service being reused say inside a winform.)
Most likely, you want to constrain dealing with HTTP particulars to the Controller (IMHO, this is obviously just my opinion). But I'd refrain from using it as a hard and fast rule.
You shouldn't be propagating http status codes down or up the line. If you do then you are injecting dependency on what you worked so hard to decouple. One of the great things about N-tier architecture is that yeah, your web layer may be primarily used for interacting with your service layer but what happens when you want to hook up a native mobile application to call it, or a windows service to call it, or a desktop app to call it. You are basically handicapping its potential by trying to persist that error up and down the chain.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have earlier developed an application that exposes a set of RESTful services. I have designed business logic implementation classes and corresponding repository classes completely stateless and they get instantiated every time there is client request. Now I am developing another application with few RESTful services. In this case, one of the services gets data from some other external service and needs to cache that data for some amount of time. I am thinking to cache that data in my application DB and provide it for each request by creating a new business class object. But here I have a doubt - is this correct design? Should I make the business logic class singleton and maintain state (i.e., cache data in memory)?
Please share your thoughts.
Thanks
I would use web server level caching instead. In asp.net you can use the Cache object, either backed by memory or an external cache provider of your choice.
After some literature study, I conclude that there is nothing wrong in having singleton classes. RESTful services are just resource interfaces for external world but how they will be managed is completely internal. Also I realized there is no need to have end-to-end mappings from data transfer objects (that take requests and send responses) to database columns. My DTOs, in many cases, map to model objects which map to DB tables but I have also designed those three items differently.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am starting a project in asp.net. I want to use 3 layer architecture. now I have problem with layers. I manage these layers like this:
but I have seen somewhere that uses App_Code and some other formats. could you please help me which one is true and standard?
App_Code is a special ASP.NET folder which is used by ASP.NET Websites. It is not used by precompiled ASP.NET applications. You can read more about the differences between the two in this article. So if UI is an ASP.NET Website you could use the App_Code folder to put some logic although this is better suited to external libraries as you have in your current design. This allows for better unit testability of this code and reusability.
Avoid the use of App_Code. Anything you put in here doesn't compile until the site is executed. Any dependency that your forms and user controls have is best put into your UI layer, outside of the main web folder. You'll have a lot more peace with objects that are compiled early rather than later.
Now-a-days I see this standard a lot:
ProjectName
-ProjectName.Core (All poco classes and interfaces)
-ProjectName.Data (All entity framework stuff)
-ProjectName.Service (All business logic)
-ProjectName.Web (All font end logic)
"Core" is reference in all projects to move data around.
"Data" is referenced only in "Service".
"Service" is referenced only in "Web".
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am creating a asp.net mvc2 project which contains multiple modules in the project.I am thinking to create supprate controller for each module, but i want to know what are the advantages & disadvantages out of it?
Seperate controllers means a Seperation of Concerns, you would have separate controllers to handle logic that should be separated. So you won't get a cluttered controller handling everything in your application. Besides clarity in your application, this brings the benefit that if you need to change one thing, you don't break other code handling other logic in the same place.
Naturally this separation is also present in your Views folder, so you'd have clear oversight what's going on where in your app.
Also, if you have a lot of dependencies that your one controller needs (like services getting different domain models) you would have these listed in one place, which would make it less clear what the primarily function of that controller is. It's nicer to have more controllers with less dependencies each.
Another benefit is that you get user friendly Urls without much effort:
www.domain.com\home\index
Pretty much spells out this is the homepage.
And:
www.domain.com\account\login
does so too.
Basically, make objects (controllers) for each "section" of your web app, like you would make objects for each functionality of the business logic.
i would read this article: Biggest advantage to using ASP.Net MVC vs web forms
since it already covered your question for a big part.