Solution Structure:
MyProject - WEBAPI
MyProject.CORE - Class Library
MyProject.Models - Class Library
MyProject.DAL - Class Library
Project References:
MyProject refers to CORE , MODELS
MyProject.CORE refers to DAL,MODELS
MyProject.DAL refers to MODELS
Project Description:
I am trying to create an application with ASP.NET MVC WEB API . so that I can call my API in future mobile applications. My idea behind this layered architecture is WEB API project will hold the front end views of my desktop application and call's the API controller methods on button click events . The event handler methods in API controller will call the Methods in the CORE project where I will implement the business logic.Then the call will be going to DAL where I will call the DB Stored Procs to insert data. As MODELS project is referred to the rest 3 , I will be able to transfer Objects across them.
Here are my questions below.
1) Can I use the same web API project above to create views of my desktop application and call the API controller methods on events like button click?
2) I don't want to expose the implementation of my business logic in CORE application to any other referencing projects. But still i need to follow a layered architecture.
How can i achieve that. Please explain with an example.
3) Is there any best architecture that i can follow with the above requirements.
4) Is this a valid architecture for WEB API and will this work?
Please take the Model example as UserModel {Name, Password, Email}
I assume you meant 'solution', not 'project'. Yes, you can keep mixed types of projects inside one solution, that is Web API for IIS hosting and WPF app that references your core.
This is where interfaces and dependency injection come into play. Create separate interface project to reference and use some dependency binding module like ninject or Microsoft Locator
When following any architecture pattern, remember that patterns were created for developers, not the other way round. What am trying to say, that when you follow any architecture, you - and only you - know what you are trying to achieve. Don't stick to any pattern if you don't know what are you doing and feel free to bend any pattern to your needs. For now keep it simple.
Yes.
Related
I want to create application with layered architecture. I have separate
Model project with only model classes
Data project responsible for CodeFirst configuration, migrations, etc.,
Service project responsible for business logic, and preserving the data in the database using EF
Dto project with classes used between Web app and service
Web project with asp.net mvc application.
My goal was to separate these projects so that Web project knows nothing about Model and Data - it just consumes Service using Dto classes, so the Web project should just reference Service and Dto. Everything was great until I configured Asp.Net Identity - in order to configure authorization I had to reference Data and Model project which I had wanted to avoid. Is it possible to achieve my goal, and (if so) how to do it.
My second question is: is my desing ok from the separation of concerns point of view?
I might separate all the ASP.NET Identity things into its own project housing both the EF data access and identity models. Think of it as separating the concerns more topically or by the subject matter, rather than by function.
So your web app would then reference Service, Dto, and Identity- and everybody seems to have their own corner of the world.
The goal, imo, is not necessarily to divvy up code by similar functionality, but to eliminate dependencies where none are needed, and to hide (or rather protect) domain knowledge into isolated and authoritative blocks.
Yes, your design is basically solid and generally works well.
I`ve already asked for something here Update view in response to web service requests AND I got the answer for most important question however I have another one related to this.
I have 2 projects in my solution (actually more but others are irrelevant in this case) - ServiceStack web services which is library type of project and MVC application. I would like to use mvc app's functions or variables (so share MVC project's memory with web service). I can do this if I move web services classes into the main project but I would like to keep it separated. I, of course, already added web service's project reference into main project (MVC) but I can't add main project references info web services project because it says that it cannot be done because it would result in circular dependencies, which isn't anything strange.
What's the best solution to either share memory between these projects or provide a communication channel between them. I don't want to, for example, make requests to my controller's public methods. I know that when you face circular dependencies it means you did something wrong while designing a solution but in this case these 2 projects are separated only to separate web services classes from the main project.
You should add a third project that includes all the common classes you need to use from both your projects.
Look at the MVC Integration and ServiceStack Integration wiki pages for docs on integrating between ServiceStack and MVC. e.g. if your MVC Controller inherits ServiceStackController you'll have access to ServiceStack dependencies and IOC to resolve any registered dependencies. You'll also be able to call ServiceStack Services directly.
I am new to MVC and Web API. I created two separate projects. One ASP.NET MVC 5 (MyUI) and other ASP.NET Web API 2 (MyApi). I would like to keep my API project separate from my UI layer.
The AccountController class in MVC project (MyUI) is essentially doing the same that the AccountController in the API project does (MyApi). I first thought about making the MyUI.AccountController a sub class of MyApi.AccountController but then I quickly realize that first inherits from Controller and second from ApiController type.
So my questions are:
In order to remove data access logic from MVC 5 project, should I
just convert the AccountController to a wrapper class which will
essentially call the corresponding methods from the
MyApi.AccountController?
Is there a better approach?
Edit:
Edit 2:
While trying to articulate the problem I realized that I was going about it incorrectly. My confusion came from the ASP.NET Identity implementations which were embedded within the API project. That needs to be moved to the Data Access layer and both controllers need to access them the same way which is a whole different can of worms :)
Thanks!!
Method 1 seems a plausible solution but what I would suggest is to create a new class library and there put your data logic. In that way, the MVC project and the Web Api project could connect to that class library.
The reason is that you never know if you write another UI layer, Service layer or other connectivity layer. All those layers could then connect to the same data logic layer.
Extract the common implementation into a separate project (a class library for instance). Your business logic must be the same no matter how you access it. After all, the web service and the site are only a view of the same information and the same control logic. In the future you might be required to write a fat client in WPF or a service in WCF and you do not want to rewrite everything, do you?
I think you are asking about layering application. basically the choice depends on requirements.If you are following data centric design check this layering
Research about DI,ORM,Repository Pattern, SOLID Principlese
We've got a solution with multiple MVC web projects and now adding a client-facing WebApi project.
The API will be a much more scaled-down version of what is available through any of the web projects (though it will likely expand much more over time), so we've come to a decision-making point for how to handle the Models.
What are the best practices for handling Models across different projects?
It's my understanding that a Model in a WebApi project will, for example, use certain property attributes which are meaningless to an MVC web application. And also as an example, the Display attribute is meaningless to the WebApi, but very useful in a View.
This leads me to believe I should be creating a separate set of Models for the WebApi, but also wondering if I'm missing something.
I understand that this could be a question that may lead to a range of opinions, so I'm mostly looking for what are considered industry best practices.
In my solution where i have Web API and MVC web app, I have the below structure
Models : My Entity/Business objects. These are created by Entity framework from my database. These are almost same as my db structure. My Repositary methods (for data access) returns either a single instance /collection of instances of this classes. My data access project is a separate class library which has been referred in other places like my web api project etc..
Web API ViewModels : The Viewmodels (POCO class) specific to the Web API interfaces/action methods.
MVC Web app ViewModels : The Viewmodels (POCO class) specific to my razor views. I had even inherited few of these from the Web API Viewmodels and added additional properties as needed.
I use a separate project for the DTOs, so that the projects that need to consume them do not get into issues with circular references.
I would have the WebApi project map your models into the DTOs. If your MVC project is consuming the WebAPI output, it just needs a reference to the DTO project. This keeps you from having to refer to the WebAPI project directly.
In my Visual Studio solution I m having following types of project:
Class Library - BusinessLogicLayer
(I m in doubt how to seperate functionality in BLL)
Class Library - DataAccessLayer
(I m in doubt how to seperate functioanlity in DAL)
Class Library - DataModels
(Contains various models like User,TimeTable,Address, etc.)
WCF Service App - To create common WCF service which can be consumed from jQuery(Web App) and WPF App
ASP.net WebForms Project - Web Pages
WPF Project - Windows application for same (As it is the requirement)
Setup project - Septup project to create installer for Windows app
UnitTest project - Project to make NUnit basd test cases
Can u please tell me whether or not I m going right way?
This is my first n-tier based application.
I m actually not clear to seperate functionality in layers even in my very first screen that is login screen.
It could be like this way from code behind file login.aspx.cs in OnClick_submit event I should create instance of UserBLL class and then I should call obj.validate(username,password) which returns a model of UserInfo. While that BLL class should itself call UserDB.Validate(username,password) method which returns model back to PersonBLL class.
If I use this scenario then every operation needs a seperate db conenction.
I also want to asks whether or not creating applications in this layered approach results in any extra memory consumption.
Please explain the scenario to me if you are familiar with this.
I don't know about others but I find working code to be a far better way of getting a handle on best practices. Therefore , I'd strongly recommend downloading the Patterns and Practices Data Access drop on Codeplex. It's a little old now but will provide you with a comprehensive reference sample for a Web (albeit MVC), WPF and tiered Services application.