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.
Related
To give you a quick overview of my application architecture, I have the following layers in my application:
Domain Model - Models the problem domain and business rules.
Service Model - Models the service contract consumed by the application.
Data Access Layer - Persistence of domain models, in this case using EF.
Services - Implementations of the service model.
Website - MVC web application.
Web API - RESTful web service API.
Now the problem is that the Web API came later; the MVC web application was the first thing that was built on top of the architecture.
I find myself having to replicate business logic and ViewModels (MVC) and Messages (Web API)...According to the DRY principle, I shouldn't be doing this, so the natural solution is to push the business logic into its own layer which is independent of the application layers.
But...this means that the business logic layer needs it's own set of models which sit between the application layer and the business logic layer. In this respect, it would not be applicable to use domain models, since these really shouldn't ever hit the application layer.
So in short, I'm looking for an industry accepted standard for business logic modelling. Is there an accepted standard for how this should work, and if so, what type of model (i.e. it's not a domain model, and it's not a view model) belongs to the business logic layer?
You have stumbled upon a contested point of discussion. I myself have struggled with this for a long time.
Object bigots will argue that you shouldn't even have a service layer. Your domain model could then be directly consumed which would eliminate the duplication of logic. Granted, those were the good old days of software modeling. With the advent of the web, apis and SOAs, we are forced to look at alternative ways of modeling our software. Enter Anemic Domain models.
Anemic Domain models essentially consist of light weight objects that resemble DTOs more than anything, with underlying services that do the heavy lifting.
The architecture you have described above seems to be a hybrid design. I am guessing by now you must have run into the issue of mapping EF classes to domain objects, which creates yet another layer of objects, unless you use POCOs, in which case you run into namespace issues and what not.
Anyways, I don't think there is an industry standard. What I can tell you is that I have seen a few patterns emerge here and there leaning towards Anemic Domain Models and it's not hard to see why. In disconnected environments (e.g. web, API), complex objects don't work very well, hence the affluence of services.
Since you have layered your application nicely and do not wish to expose your domain model objects, I would suggest using Anemic Models in your service implementations. These would essentially function as DTO objects that can be reused and serialized if the need be, but can also implement basic logic that may even map back to functionality implemented in the services.
On a final note, there is no one-size-fits-all. Use the right tool for the job. Patterns are meant to be guidelines, not step-by-step instructions, so make sure you feel free to tweak them in order to fit your particular needs while retaining the general idea.
You can read more about Anemic Domain Models here:
https://en.wikipedia.org/wiki/Anemic_domain_model
Make sure to check out Martin Fowler's objections to Anemic Domain Models as well:
http://www.martinfowler.com/bliki/AnemicDomainModel.html
In my n-tier .Net Application I got next layers:
Data Access Layer (EF)
Business Layer (Validation & Business Logic)
Presentation Layers (1 MVC Controller and many API Controllers)
I found, that my Business Services only validate business objects, call CRUD DAO methods and return results to Api Controllers.
So, I doubt: may be Web Api Controllers should be used as Business Services?
Interesting, just answered a similar question...
So I woudn't do it I were you.
Here's just a few disadvatages of the approach from the top of my head:
Performance - a redundant HTTP roundtrip in Web MVC project.
Separation of concerns - most of the time the functionality provided
by API differs greatly form UI for the same project/application. You
might want to limit the API to a few methods with a strict contract.
In case you want Web API to be a layer between Web MVC and your DAL
you will have to expose all functionality you need for UI as well.
Also you might want to have different authorization and
authentication mechanisms. Very often API exceptions handling is
also different as well as input validation.
Maintanance - everytime you need to make a change required for UI
only you have to make sure it doesn't brake your API clients. Also
API versioning is a very important topic and mixing it with most UI
changes makes this process even more difficult.
Probably for now you application is not that complex but from the design perspective your solution is much more flexible now than it will be if you decide to put Web API between your UI and DAL layers.
N-Tier applications and multi-layer are not popular among the new wave of developers. Keep in mind, that just because something is not popular, among a group, does not mean that it does not have merit.
Pros of MVC:
Separation of Concerns
Unit Testing
Does a multi-layer MVC application using a Web.API have merit:
I know this will be met with some discontent and disagreement. However, my concern is that single purpose application developers are not giving consideration to enterprise development. Enterprise development, load balancing, manageable code maintenance, and true Separation of Concerns are only possible with multi-layer applications that can easily lend themselves to N-tier.
Many developers are operating in environments that demand that they design and implement data structures in SQL, create and maintain models and CRUD functionality, develop controllers and design good looking and friendly views. The MVC model utilizing Entity Framework makes this a manageable task for these small to moderate platform developers.
In the Enterprise, separating the Business and Data Access layers from the User Interface makes real good sense. Right now MVC is a popular and very functional platform for efficient and usable User Interface development. What will be the UI platform in ten years? Separating the UI from the other layers gives more life to the work spent developing the business logic. Not to mention, that it allows for accessing data on multiple platforms today.
Multi-layer MVC using Web.API has these advantages:
True Separation of Concerns
Supports Unit Testing
Makes the Business logic and Data Access logic more scalable and reusable than MVC alone.
Supports data processes without page refresh. (REST)
CONS:
- Does not easily support use of Entity Framework. (Which is not ready for the enterprise yet anyway)
You could have your code as part as your model, and that would even be considered as good separation of concerns since MVC is build for that.
But what my preferred thing to do is keep logic in a Business Layer of it's own. The reason for that is, I think, better separation of concerns. I like using IoC, so there might be different configurations that I route thought different running solutions. Or, I might have another UI/API/Project that uses the same logic layer.
As for the overhead, it has a little overhead, but I think worth the trouble comparing to the actual overhead in code it creates.
I agree with others here, looking into using strongly typed views, the controllers would only create an instance of the viewmodel and send it on to the view. The view model then is the intermediary to the data services layer. I personally create all my entities using EF in a different project just to separate function. The view model can either call EF directly or you can add another layer of pre-canned EF queries which the Viewmodel uses just to populate the view collections. This would look like this:
[View]-[Controller]-[Viewmodel]-[Optional repository and interface to EF]---[EF]
In the interface to EF you would catch all DB errors when trying to get information and post back to the view according to your design.
The beauty of strongly typed views is that they post back and forth from the View and can contain methods which you can call at will. Because they are a pseudo model for the view, they can also have properties specific to the view which may be used at the business layer. I pass view models around quite a bit were warranted. (After all they are just a pointer)...
You can implement business logic/validation/calucations in the actual model/entity classes rather than ApiControllers, otherwise you will end up with so much code in your controller which is not really a good thing.
Also you can use DataAnnotations Attributes to perform your validation which sits outside of your controller. for.e.g. http://msdn.microsoft.com/en-us/library/ee256141(v=vs.100).aspx
Almost all examples of DDD within the Alt .NET community are applied to web development; what I would like to see are some examples of DDD applied in scenarios where the client handles most of the business logic and the server is simply a web service for CRUD using DTOs [1].
I'm currently working on a product that has an anemic domain model. Coming from years of web development, this sort of thing would typically make me cringe; however, I'm not sure how I would go about structuring this code around the DDD principles. In a web app, I have direct access to the database at the point where I handle business logic (implemented within my domain model, invoked by the controllers), which means that I can easily have a rich domain model and use an ORM for CRUD. But, in my current project, DTOs are the only sane way to transfer data. 80% of the business logic is implemented in View Models (this is a WPF app), the other 20% percent is located in stored procedures - and 100% of the DAL is hand written ADO .NET. There's really isn't a lot of business logic implemented within the web services, so there aren't any "entities" to be found in the solution - they're all DTOs.
How could I introduce DDD into this sort of client/server architecture? What sort of experiences have you had, and what approach did you take? What patterns would you suggest? I haven't had much time to grok CQRS, but something tells me it could related - is that so?
Foot notes
Perhaps this is the wrong question to be asking. In this type of client/server WPF scenario, would it make sense to follow the web app paradigm, where 99% of the client's focus is on display logic?
This is funny, because I often wonder how DDD can be applied to web development.
I don't mean this to be a comprehensive answer to your question, but you might find something useful among the responses to an old question of mine: Should I map a DTO to/from a domain entity on both client and server sides?
As a very general answer to your question, I'd say that you could move logic out of the view models and into a client-side domain model (since it sounds like the server side is working just fine without any concept of a domain model). You'd use the DTOs coming out of the web service to "hydrate" these entities.
If you're creating a smart client, then you want to leverage the ability to maintain state and perform logic directly in the client (so, "no" to the footnote).
Several "parts" (a WinForms app for exmaple) of my project use a DAL that I coded based on L2SQL.
I'd like to throw in several WebApps into the mix, but the issue is that the DAL "offers" much more data than the WebApps need. Way more.
Would it be OK if I wrapped the data that the websites need within a web-service, and instead of the website connecting directly to the DAL it would go through the web-service which in turn would access the DAL?
I feel like that would add a lot of overhead, but on the other hand, I definitely don't like the feeling of knowing that the WebApps have the "capabilities" of accessing much more data than they actually need.
Any input would be greatly appreciated.
Thank you very much for the help.
You can either create web services, or add a repository layer that presents only the data that your applications require. A repository has the additional benefit of being a decoupling layer, making it easier to unit test your application (by providing a mock repository).
If you plan on eventually creating different frontends (say, a web UI and a WPF or Silverlight UI), then web services make a lot of sense, since they provide a common data foundation to build on, and can be accessed across tiers.
If your data access layer were pulling all data as IQueryable, then you would be able to query your DAL and drill down your db calls with more precision.
See the very brief blog entry I wrote on Repository and Service layers using Linq to SQL. My article is built around MVC but the concept of Repository and Service layers would work just fine with WebForms, WinForms, Web Services, etc.
Again, the key here is to have your Repository or your Dal return an object AsQueryable whereby you wait until the last possible moment to actually commit to requesting data.
Your structure would look something like this
Domain Layer
Repository Layer (IQueryable)
Service layer for Web App
Website
Service layer for Desktop App
Desktop App
Service layer for Web Services
Web Service
Inside your Service layer is where you customize the specific calls based on the application your developing for. This allows for greater security and configuration on a per-app basis while maintaining a complete repository that doesn't need to be modified until you swap out your ORM (if you ever decide you need to swap out your ORM)
There is nothing inherently wrong with having more than you need in this case. The entire .NET 4 Client Profile contains over 50MB of assemblies, classes, etc. I might use 5% of it in my entire career. That doesn't mean I don't appreciate having all of it available in case I need it.
If you plan to provide the DAL to developers that should not have access to portions of the data, write a wrapper or derive a new DAL. I would avoid the services route unless you're confident you can accommodate for the overhead.
Sounds like you are on the right track. If many applications are going to use the this data you gain a few advantages by having services with DTOs.
If the domain model changes, just the mapping to the DTO needs to change. You can isolate the consuming application from these changes.
Less data over the wire
You can isolate you applications from the implementation of the DAL.
You can expose different services (maybe different DTOs) for different applications if it is necessary to restrict what parts of the object model should be exposed.
I am an experienced developer but I am new to web application development. Now I am in charge of developing a new web application and I could really use some input from experienced web developers out there.
I'd like to understand exactly what experienced web developers do in the code-behind pages. At first I thought it was best to have a rule that all the database access and business logic should be performed in classes external to the code-behind pages. My thought was that only logic necessary for the web form would be performed in the code-behind. I still think that all the business logic should be performed in other classes but I'm beginning to think it would be alright if the code-behind had access to the database to query it directly rather than having to call other classes to receive a dataset or collection back.
Any input would be appreciated.
If you go strictly with asp.net (and don't use MVC models), then you are on the right track considering N-tier development and separation.
Your code-behind should be related to presentation/UI, and should rely on middle tier layers for business logic etc.
In general the easiest way to split up the app, is to have multiple projects in a VS solution, such as:
ASP.NET Web application project (Presentation/UI)
C# class library - Business Logic Layer
C# class library - Data Layer
Database (SQL or otherwise)
You can of course have many other libraries and layers as needed, but essentially the n-tier approach that works in non-web environments applies well using the same principles here.