I've been checking quite a few examples related to Web Api, and they all create the model in the Models folder contained with the Web Api project but I'm curious as to how this should be handled if you want to use/re-use these models with various projects.
In the past, when using WCF REST, I would have created the following:
Business Model Project (PCL)
Business Layer Project
Data Layer Project
SQL Data Layer Project
WCF REST Project
Web App
Windows App
Third-Party Web app (javascript)
Mobile App (Xamarin)
Projects 2 to 9 would have all been referenced to Project 1 or objects would be created dynamically when using JavaScript. The business object project only contained POCO objects, most decorated with DataContract/DataMember attributes.
Can the same logic/Project breakdown be applied when using Web Api? Is it recommended or will I face problem at a later stage?
If it's not recommended, am I suppose to duplicate all my models? Doesn't seem to make sense so I thought I'd ask.
Thanks.
Short answer, YES. The same logic/Project breakdown can be applied when using Web Api. This is also how I implement my architecture. Your Web Api would just be another layer in your architecture. By doing it that way you will allow for greater re-usability of the models (DRY) and maintainability.
Related
I have created Business and DataAccess Layer for my web project using dotnet core.
I have added Data access reference in Business layer and referenced the business layer in UI (web project) layer.
I seen, I am able to access my Data access layer from my UI (web) project. I am really wondering, It can lead to violation of any application design.
Appreciate help, if anybody come across this and how to restrict access to data access layer from UI.
Yes, an indirect dependency is a dependency too.
And your toplevel (MVC) project has to reference everything, direct or indirect, in order to get all modules loaded. And to set up the dependency injection.
You can get better separation by introducing an interfaces layer in a separate project. For example IBusinessClass and IDataAccessClass.
That works for everything but the main project so if you want this particular separation from your example, move your Controllers to a separate project and depend that on the IBusiness interfaces only. Though I'm not sure how that works with MVC's conventions.
I am starting to work on a new project so working on laying on the architechture at this moment.
So basically we want to keep a service oriented architecture using MVC web api.
So I had the following structure in mind:
Project.Core (All Poco classes)
Proect.Data (All entity framerwork)
Project.Service (All Web API ??)
Project.Web
We would be working for the first time on webapi here. So wanted to know how do we intergrate webapi here.
Most of the articles we saw read had created a mvc web application and had selected webapi in that. But we
were looking to create separate service layer just for webapi. Is this the correct practice to do that or
I am missing something here.
We basically wanted not to have a tight coupling b.w MVC web and web api here. If we create web api as part
of mvc then how can we separately access our web api.
WOuld appreciate inputs.
I normally use the project template provided by Visual Studio. Choose Empty ASP.NET project template and then select Add folders and references for Web API. It will create the folder structure needed/recommended purely for a Web API project without any MVC reference. I generally create a separate project for Data Access and use that from the Web API project.
I'm trying to learn dependency injection. The book/example I am following seems to be using an MVC project as just the UI layer within a broader architecture. The example includes a separate project for the domain layer and yet another project for the data access layer.
When I first learned MVC I came away thinking MVC was the entire architecture. V for view for UI layer, C for controller for domain layer, and M for model for data access layer.
So is using an MVC project as only the UI layer a proper and/or commonly accepted application of the MVC framework?
So is using an MVC project as only the UI layer a proper and/or commonly accepted application of the MVC framework?
Yes.
While it is possible to make an application entirely within the context of ASP.NET MVC, doing so means that the application will have to be written from scratch to use a different UI framework. Isolating the business logic into a separate set of services that are not coupled to ASP.NET MVC means that only the top layer would need to be replaced to move to a different UI framework, which also means that the application's lifecycle may extend beyond the end of ASP.NET MVC and/or it can be made into an application with a different UI framework (WebApi, WPF, etc) without too much trouble.
The purpose of dependency injection is to decouple your services from all other parts of the application, including each other. So by extension, it is only natural to build the business layer separately from the UI layer. Whether you physically have them in one assembly or multiple is really just a matter of preference.
Applying SRP to the MVC design pattern will lead you there. Same goes for MVVM. You are extracting logic from Model to other classes like Interactors, Services, Repositories etc.
From any point of view this is perfectly normal(and desirable). Your Model is just an abstraction of Several different layers.
I would suggest you to take a look at VIPER (not a car) - https://www.objc.io/issues/13-architecture/viper/ and you will see something that is occuring to you right now.
I am working in my Application Architecture and i am wondering if i should use WCF or not.
The UI will be a public website written in ASP.NET MVC 3 but in the future possible Iphone/Android applications...
So now i have a data layer (Entity framework + repository), business layer (Class library)
and UI (ASP.NET MVC) communicating via ViewModel.
I understand that in a good SOA application the business layer should be exposed as a webservice but i am wondering about performance issues, beacause my website traffic will be high and hosting the WCF and the website in IIS in the same machine is a waste of time and of performance since to communicate they have to serialize/deserialize objects.
Is keeping my business layer in a dll (class library) and deploy it in the ASP.NET application better then hoting it in a wcf service ?
Thanks for help.
http://geekswithblogs.net/BlackRabbitCoder/archive/2010/06/13/premature-optimization-and-performance-anxiety.aspx
I think that leaving things as just a dll for right now would be the simplest solution until you firm up your requirements for iphone/android solutions. We use WCF extensively where I work, and it can be very fast.
That said, creating a WCF service on the chance you might need it later seems premature and its always easy to add a web reference later and remove the dll. You can't get the hours spent on a WCF service back (and the risk of needlessly adding another layer between your app and its data) as easily.
I've been using ASP.net MVC for about two years now and I'm still learning the best way to structure an application.
I wanted to throw out these ideas that I've gathered and see if they are "acceptable" ways in the community to design MVC applications.
Here is my basic layout:
DataAccess Project - Contains all repository classes, LINQ-to-SQL data contexts, Filters, and custom business objects for non-MS SQL db repositories (that LINQ-to-SQL doesn't create). The repositories typically only have basic CRUD for the object they're managing.
Service Project - Contains service classes that perform business logic. They take orders from the Controllers and tell the repositories what to do.
UI Project - Contains view models and some wrappers around things like the ConfigurationManager (for unit testing).
Main MVC Project - Contains controllers and views, along with javascript and css.
Does this seem like a good way to structure ASP.NET MVC 2 applications? Any other ideas or suggestions?
Are view models used for all output to views and input from views?
I'm leaning down the path of making view models for each business object that needs to display data in the view and making them basic classes with a bunch of properties that are all strings. This makes dealing with the views pretty easy. The service layer then needs to manage mapping properties from the view model to the business object. This is a source of some of my confusion because most of the examples I've seen on MVC/MVC2 do not use a view model unless you need something like a combo box.
If you use MVC 2's new model validation, would you then validate the viewmodel object and not have to worry about putting the validation attributes on the business objects?
How do you unit test this type of validation or should I not unit test that validation messages are returned?
Thanks!
Interesting.
One thing I do differently is that I split off my DataAccess project from my Domain project. The domain project still contains all the interfaces for my repositories but my DataAccess project contains all the concrete implementations of them.
You don't want stuff like DataContext leaking into your domain project. Following the onion architecture your domain shouldn't have any dependencies on external infrastructure... I would consider DataAccess to have that because it's directly tied to a database.
Splitting them off means that my domain doesn't have a dependency on any ORM or database, so I can swap them out easily if need be.
Cheers,
Charles
Ps. What does your project dependency look like? I've been wondering where to put my ViewModels. Maybe a separate UI project is a good idea, but I'm not entirely sure how that would work. How do they flow through the different project tiers of your application?