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.
Related
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.
I am trying to get a hold on WebAPI so please excuse if the question is too naive to ask.
Been hearing that WebAPI is using MVC and is integrated in to it.
Just created a sample WebAPI project but under References I find not System.Web.Mvc dll.
Why? Or am I missing anything important?
EDIT:
About System.Web.Mvc, the MSDN says the following paragraph:
The System.Web.Mvc namespace contains classes and interfaces that support the ASP.NET Model View Controller (MVC) framework for creating Web applications. This namespace includes classes that represent controllers, controller factories, action results, views, partial view, model binders, and much more.
And it should not be there. ASP.NET Web API is very similar to MVC, buit is not integrated with it or whatever. Web API can live completely outside of MVC framework perfectly fine. Which is good - while building HTTP service you wouldn't want to include any HTML rendering features whatsoever into your project.
Think of it that way - System.Web.Mvc contains end-user-facing features that MVC uses, like views, view results. WebAPI is not a end-user-facing thing, it does not generate HTML or run javascript. Purpose of Web API is to provide means for creation of HTTP services - very different from MVC framework.
MVC and Web API share several similar approaches. Take controllers for example. Looks like they behave similar in both frameworks. However you may discover that implementations are different. MVC uses System.Web.Mvc.Controller, while Web API uses System.Web.Http.ApiController. More detailed explanation on the reason why is here. On the other hand - routing. Both frameworks use the same implementation of routing which resides in System.Web.Routing.
Frameworks are similar, but can exist completely separately. That is why there is no reference between them.
For Visual Studio Express 2013 for Web do the following:
New Project > Web > ASP.NET Web Application > Web API > OK
This should work, the Add folders and core references for: MVC and Web API should be automatically ticked by VS.
100% working - I've just created a project and all the references are there.
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.
I have a wpf application with multiple projects. I'm wondering if it's best to have one project that handles all the web services and have each project reference this one project. Is this even possible, or does each project need to handle its own web services?
This is possible and would be a great way to seperate your web services to be used by other parts of your system.
If you create one project that has WCF, ASMX or any other type of service you can add a web service reference to your other projects or hook it all up manually! The individual projects can pass in configuration properties (URLs, or any other pieces of data) or defaults could be set in the web service project itself!
You can absolutely do that! In fact, I'd say it's preferred - that way your single web service project can be re-used by different clients, whether it be WPF, Silverlight, or ASP.NET MVC (using AJAX). For example:
WebServiceProject
WpfProject
SilverlightProject
Projects 2 and 3 would have a Service Reference back to project 1, thus eliminating the need to possibly duplicate data access code.
Here is the MSDN reference page for adding Web References in Visual Studio.
Hope this helps!