I have the following situation: I have to create a website and a web service that will share a part of the functionalities.
This is why I do not want to write code twice.
I have thought of the following architecture:
MyApp.BusinessLogic --> here we save the DataModels to the database
MyApp.DataAccess -> DataModels & Entity & mapping
MyApp.UI.Models -> ViewModels
MyApp.UI.ServiceLayer -> Acceses the Business Logic, creates the UI ViewModels for the website, and transforms the ViewModels back into DataModels for saving with the help of the BusinessLogic Layer
MyApp.WebSite
MyApp.WS.Models - >Ws Models, these will be the objects passed between the client and the WS
MyApp.WS.ServiceLayer -> Accesses the business Logic, creates the WS Models for the web service, and transfoms the WS.Models back into DataModels for saving with the help of the BusinessLogic Layer
MyApp.WebService
Is the architecture overkill ? What problems will I encounter ? Will I have problems with the controllers in the ASP.NET MVC website ?
When I design my applications I do it like this. My only issue is the dull copying of models to view models. The best way to overcome this to use AutoMapper.
I would though create some unittests because there is a high risk of breaking the app when changing the services (and visa versa). Unit testing would tell you that early on.
Define basically :)
If you want to reduce the code usage, why not create your service, then just consume it in the app?
So if you would have something like...
Foo.DataAccess
-Foo.BusinessLogic
--Foo.ServiceLayer
Then have that referenced by:
Foo.WebService (including models for view/update... but probably simplify externally)
Then use
Foo.WebApp
and have this consuming Foo.Webservice to make the data calls on it's behalf
Having UI and web service models increases your code duplication, you could use something like Fluent validation to let the service handle your validation, and enhance the basic validation system.
Related
I am currently working on an intranet website that uses Active Directory and SQL Server 2008. I have chosen ASP.NET's MVC design pattern and am now trying to figure out how to get a proper architecture for my project concerning the Data Access part using Entity Framework. I have been struggling for days in order not to go in the wrong direction (knowing that I'm the only developer in my company, it's my first experience and nobody knows about recent Frameworks). I have read about architecture and how to do it right, but I am not sure I grasped everything correctly (How do architect an ASP.Net MVC app with EF?).
Here is what I was thinking of doing, each layer having their own project (pardon my drawing skills):
Controller(MVC Project) ---uses---> Service Layer (Project) ---uses--> EFDal (Project)
^ | ^ |
| | | |
|<-------<-----returns ViewModel |<---------<------returns Query Result
EFDal is EntityFramework Data Access Layer.
And from what I understood, Service layer would contain methods that call the DAL which in turn is used to access data.
Do you see something wrong in my approach?
Am I right in saying the Service Layer, is the one containing all operations? (eg: Searching a user in DB -> Service Layer launches search by calling EFDal which returns the value, and in turn Service Layer returns a ViewModel to the controller)
(also see: Creating a Service Layer for my MVC application?)
Finally, Should my Service layer classes implement Interfaces for persistence purposes?
As a student we only used MVC pattern for our projects, and never had to expand the solution with new projects because we worked on small projects. Here I feel like misconceiving the architecture will end up in disastrous maintainability. Thanks for your help!
You're almost in the right direction. However, the ViewModel in this case should reside in the application layer, i.e. your MVC layer. The service layer should in turn return a data transfer object, more commonly known as the DTO.
Think of the ViewModel as a simple POCO class that is built for the View, it can be a collection of various DTO returned by various services from your service layer.
Benefits of DTO
You are not directly exposing your domain entities, i.e your EntityFramework POCO classes. However, a case can be made for a project small enough to avoid DTO all together.
In case in the future you decided to add an WebAPI function along your MVC project, say, for an iPhone application. The new application uses the WebAPI that also consumes the service layer, most of the service layer codes can be re-used since they return DTO classes and not ViewModel that is constructed for the View itself.
For your Data Access layer, no one explains better than this guy. Entity FrameWork With Repository Pattern
As for project structure, I would suggest an onion architecture. Onion Architecture. If you can understand this article well enough, you should be all set.
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.
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 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
I am new to asp.net mvc. I want to divide presentation layer with logic layer. I know it is already done in asp.net mvc but I want to have presentation layer on another machine. I don't know if this what I want to do, is possible, but just wanna ask. I want something like this: User enters address 123.123.123.123/Home then that request is redirected to presentation layer. Presentation layer is then asking "Logic Server" for data(from database or smthing) and logic server returns it back to presentation layer which presents the page to the client.
My overall goal is to make framework which allows us to do this easily.
And my questions:
1. Is it worth doing it?
2. Is it possible with asp.net mvc ?
3. Is there anything like this?
I wanna also extend that framework to work independent from technology. And the presentation layer would be a "connector"
You can do this by having some kind of Service Oriented Architecture. In your MVC app you have a services layer, this could talk to a WCF service or something similar on your network. Your WCF service would then talk to another machine for data storage, do the required business logic and return simple DTO's.
Is it worth doing? This depends on you. Is there a good reason to do this? It shouldn't be that hard, and if you write your MVC app correctly the services layer will abstract away the fact that the service is on another machine or the same machine so you have some flexibility to change your mind later.
Is it possible? Yup
Is there anything like this? I'm sure there are plenty of people out there who are doing/have done what I have described
Quite strange architecture.
You can indeed use SOA. It has many advantages and it's well studied and supported.
However, I wouldn't use SOA for the presentation layer (and I don't remember to have seen that never).
You'd normally have the business logic in a layer, and expose it as Web Services (that's SOA), and all the presentation (in this case creating MVC view models, and returning the rendered views to the browser) in the same application. (See note at the bottom)
It has no sense to separate the Presentation in a SOA layer, because you cannot reuse it for anything else. I.e. you cannot use that presentation layer for a windows application, or to use it for a java web application.
However, if your business logic is exposed in a SOA layer, then you can use it with any kind of UI you want: windows forms, WPF, or even a Java Web Application.
Apart form this there is a tigh knot between routes, and controllers in MVC. You cannot easily achive what you want to do. However, you can easily make an MVC presentation layer (routes, controllers and viewws), which uses the business layer exposed as SOA from your controllers. That's much more natural.
Is it possible: of course, but non-standard and har to do.
Is it worth: No it isn't. Your canot reuse it with a different techonlogy. Which is the advantage?
Is something like this: neve seen it!
NOTE: having a single app doesn't mean having a single layer. But you don't need to separate them in different applications or SOA layers. If you use MVC correctly you'll have a very clear separation between Views (which render the result for the browser) and controllers (which prepare the View Models for rendering the Views) and the Business layer (which can be in a different app, exposed as SOA services, and consumed from this controllers). In fact, it's hardly impossible to make a bad use of MVC if you have into account that you need View Models, which are objects specifically created for the view to be rendered, instead of using directly the business entities.
For example a vie model can have a customer's data to edit it, but probably will have several lists of options for populating drop down lists. If you don't use view models, you'll soon have problems.