Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have been working with asp.net core web api for the past few days, I am familiar with MVC and SOC etc but I got confused a bit with the core mvc tutorials.
So in all the tutorials (to keep them simple) they put the business logic inside the Controller, but this is ofcourse not compliant to MVC.
In general I have created:
Model (to create the DB structure through EF)
Controller (to serve the endpoints and act)
Repositories (to provide the query logic to the DB)
Now I am bit confused with Services and also where am I supposed to put the business logic? I mean the Model is one place, but I dont want my controller to access the model directly but more like a Facade/Factory.
How do we achieve this in aspnet?
You can find my working repo at https://github.com/drakoumel/DatacircleAPI
I hope that after I can get a good explanation of this, to write it in the documentation of stackoverflow to help others.
There are so many approaches to this and there is not a single correct answer to your question.
Basically, the models you use in your views should not be the ones, that you persist in your database. Therefore, what you can do for example, is create a 'service' layer, so controllers operate on services, and services operate on repositories. This way you achieve a clear separation of concerns between each 'layer'.
First of all, keep persistance models and business logic out of controller. The only logic that belongs to a controller is application logic.
Secondly, introduce business logic layer (AKA. services layer), in which your business logic belongs. You can also create separate models in that layer, so your controllers do not operate on the models that represent your database entities, and you just apply mappings between models that services expose to your controllers and models that they pass to the repositories. Take those services as dependencies to your controllers. Your services will also take your repositories as their dependencies.
This way your controller has no idea what your business logic is - it only knows that it has to call some service which takes care of everything. Your service has no idea about where it's being used, he knows nothing of controllers, views or the way your data is presisted in the database - it just executes your business logic. And your repositories just persist your entity in storage of your choice, they only know their entity model and how to persist it. They haven no knowledge that there are services, controllers or views. The benefit which you get from is that when you decide to change your code, whether it's the business-validation logic of minimum allowed customer age or the mechanism or saving your entity, you are likely to do it in just one place in your code, place that is responsible for that specific thing.
Keep in mind that is the minimal separation of concerns between those components that you can do. Be aware that everything depends on your case and creating simple layers between presentatio, business logic and data persistance layers is not always the right or trivial thing to do, as it might sometimes be tricky not to leak your business logic into layers other than where they actually belong.
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
Since I'm new to Xamarin forms, I'm not quite aware of How to arrange your Xamarin form project in a good folder structure?
For eg. I have a project which contains following files :
Network calling
Database handling
Views creations
Model-View bindings
Utilities etc.
NOTE: Xamarin Form itself has Xamarin.iOS and Xamarin.Android solution folders and the above mentioned files could be common to both Android and iOS.
Typical Application Layers
Data Layer – Non-volatile data persistence, likely to be a SQLite database but could be implemented with XML files or any other suitable mechanism.
Data Access Layer – Wrapper around the Data Layer that provides Create, Read, Update, Delete (CRUD) access to the data without exposing implementation details to the caller. For example, the DAL may contain SQL statements to query or update the data but the referencing code would not need to know this.
Business Layer – (sometimes called the Business Logic Layer or BLL) contains business entity definitions (the Model) and business logic. Candidate for Business Façade pattern.
Service Access Layer – Used to access services in the cloud: from complex web services (REST, JSON, WCF) to simple retrieval of data and images from remote servers. Encapsulates the networking behavior and provides a simple API to be consumed by the Application and UI layers.
Application Layer – Code that’s typically platform specific (not generally shared across platforms) or code that is specific to the application (not generally reusable). A good test of whether to place code in the Application Layer versus the UI Layer is (a) to determine whether the class has any actual display controls or (b) whether it could be shared between multiple screens or devices (eg. iPhone and iPad).
User Interface (UI) Layer – The user-facing layer, contains screens, widgets and the controllers that manage them.
Each of these layers represents an individual Solution Folder.
And each Layer should also be a different ClassLibrary(Portable)(see Encapsulation)
Also worth reading in this documentation:
Encapsulation, Separation of Responsibilities, Polymorphism
Taken from Xamarin Developer Guide - Achitecture
I also found some more info here.
There isn't a full agreement on which option is better - using Shared projects or Portable Class Libraries, but those are options for code sharing.
Personally I agree with Miguel de Icaza, Xamarin lead that if you don't share your code across other apps Shared projects are better, but as he said some people in Xamarin think opposite.
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 6 years ago.
Improve this question
I'm currently trying to refactor a C# MVC application in spite of having limited experience of the pattern. Reading around the subject, I seem to constantly blunder in to dimetric opposite opinions on best practice.
My biggest problem is that there's way too much stuff in the controllers. They work, but they're full of business logic which is hard to restructure and to test. Models are mostly just thin DTOs. So, where do I start putting this useful business logic in order to rework it and test it?
A lot of people say it should go in the model. But then you get some people saying it should go in the controller after all. And other people telling you that the principle of the model containing data and NOTHING ELSE is fundamental to the pattern.
Then you get people telling you it should go in a fourth type of class, a ViewModel. Now I've worked on MVVM in WPF and I'm familiar with this paradigm. But adding it to MVC just seems to replicate a lot of work that's done elsewhere, for no better reason than blindly following a pattern dictate.
Yet another option is to put it in some sort of helper class. This seems a common suggestion, which I won't link. But doing that seems a wasteful use of another class which has no point to exist outside of providing functions to a single controller. And that would seem a fundamental violation of OOP principles.
Is there a definitive "correct" answer to this? If so, why is there so much confusion? If not, how do you go about gauging the best solution in this morass of opinion?
To me, the M in MVC stands for view model, it contains the data needed for the view to do its work, so that the view can remain as dumb as possible.
This view model is created in the controller and passed to the view, but as you said, the controller logic should be kept small - so no business logic here.
This business logic belongs in services - which could be remote services exposed with WCF, or a web API, or just a class library with methods in your web site.
So, summarized:
the controller calls the services to get data in the form of a model. Business logic is inside these services, the model returned is just POCO.
the controller creates a view model based on the received model, which contains the properties in the format which is best for the view.
the controller passes the view model to the view, which uses the view model to build itself.
I don't believe there is a definitive "correct" answer. I believe it's all in preference and how complex your data manipulation is.
At my company we use helper classes/a service for the purpose of organization. Our controllers do not contain any functionality except for taking in a model, manipulating it, and spitting it back to the view.
We have a vast amount of data manipulation, and to do that in the controller would be a horrible mess.
Most people would agree that no logic should be in the controller. The difference is where that logic should be. For my company, it would have been ridiculous to put it in the models themselves because of the sheer volume of manipulation that takes place. If there isn't a large amount of manipulation I would put it in the models.
On the project I am currently working on, we have kept our Controllers reasonably free of Business Logic as we have separated them out into Units of Work. I believe this pattern was adopted to allow us to swap the Units of Work in and out depending on the client etc.
Where as the previous project I worked on was all in the controllers and broken down into smaller shared helpers where necessary.
I don't think there is strictly a correct way or an incorrect way. The majority of the time it seems to be down to personal preference of the developer.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have read a lot about MVC, and I have even written a modestly sophisticated data-driven MVC mobile web app in .Net, but (since I am still learning), I did not see what to put in the model. The app had a dozen or so views, a primary controller, and helper files for SQL interactions and custom data types. I was able to data bind just fine without using the model, and custom data types worked as anticipated. Please be kind, what am I missing? What is the purpose of the model, and why should I be compelled use it (other than it being a standard)?
MVC is primarily a User Interface design pattern. The Model is a container for "everything else," everything that doesn't have to do with UI.
In general, you push as much logic as you can back from the View into the Controller or a ViewModel, and you make your controllers as thin as possible by pushing as much logic as you can back into the Model. So the short answer to "what goes in the Model" is "everything that doesn't go into a View, ViewModel or Controller."
Specifically:
Domain objects, like customer
Services
Business Logic
Server-side validation
Object-Relational mappers
Database
Repositories
Simply put - "The MVC Model contains all application logic (business logic, validation logic, and data access logic), except pure view and controller logic.
With MVC, models both hold and manipulate application data."
You are not following the standard MVC pattern if you ignore the Model all together. However, as you found out - you don't need to use it. You can call into the database directly from the controllers and return types you've defined in the DAL (Data Access Layer) - which indirectly you are using as the Model in your design. This isn't good practice.
You should be compelled to follow the pattern so you achieve 'Separation of Concerns' in your application's architecture. You can find a lot of information online about this topic as it relates to the MVC pattern.
Model Definition
The View is a template that can be filled by passing a model containing data into it.
It allows the view to be customized depending on what the model contains.
How else are you filling data into your view?
Maybe jQuery gets?
In your case, the "helper files for SQL interactions and custom data types" is your model. The model is an abstraction over the true data source, eg the database.
For small projects, what you have done works just fine. As projects get larger though, binding the view directly to the database/model and not fully abstracting the model causes more and more problems.
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...