I've found out n-Tier web application concept like following categories:
1- Database (including database business and table or store procedures and all database stuff)
2- Web. Data (including entities and repositories)
3- Web. Model (including not entities some simple model can transfer to client)
4- Web. Business (in some application is admitted it is not mandatory but it includes some functionality such as how to calculates things)
5- Web. Service (including web API on SOAP restful application)
6- Web. Security (it includes some custom security as you wish but it is not mandatory)
7- Web. Client (including client-side functionalities like jquery, mvvm and some other like authentication, securities implemented in UI)
8- Web. Extension (including extra helper methods and wrapper objects)
9- Web. Handler (including all handler and modules)
These layers could be placed on different projects they could be implemented by MVC or even by asp.net of course with the same concept.
I was wondering if my understanding was right or not? or got any better idea? Could you expand them more or are they limited and enough?
Please guide me what are standards about them?
Did you look MyPrettyCMS Framework in codeplex ?
It's exactely that...
https://myprettycms.codeplex.com
In the next release, it includes Web API and Web API OData Handling.
If you want to follow the developer group, find the Linked in group : myPrettyCMS Happy Contributors Associates
N-tier concept is wider than just listing the exact tiers. This concept helps to divite your application to manageble and isolated levels, which you could change, re-design, substitute without breaking and re-writing the entire application. The number of tiers could vary depending on technology stack you use.
read more here: http://en.wikipedia.org/wiki/Multitier_architecture
You should try looking into the XWA architecture if your primary concern is web applications.
http://madeyski.e-informatyka.pl/download/23.pdf
XWA architecture builds atop the concepts know from the MVC and PCMEF.
Related
I am having one client who wanted to have a website along with an app on iPhone and Android too. So, I am worried about how to structure my MVC solution architecture to best suit the requirement and re-use the business logic among all the platform using Web API.
Can any one suggest the architecture in bit detail to prefer in the above mentioned requirement.
Consider an MVC4/EF5 project:
Creating a web application which will have 3 modules.
Based on the customer license, we will enable or disable 1-3 of the modules.
Each of the modules will deal with a handful of common tables (Users, Company, etc).
Each of the modules will deal with tables specific to their functionality (PO's, Timesheets, etc)
An admin portal, admin users in a seperate table from regular users.
data passed to views using view models
eventually there will be a JSON service for exposing parts of the applications functionality.
There will be multiple deployments of this application with slight customization (beyond just enabling/disabling each of the three modules).
The Plan so far:
Separate dll for Model
Separate dll for each Module/Functional area.
Separate dll for the ViewModels
Separate dll for admin portal
Seperate dll for the web service
Questions:
Is anything gained by a seperate dll for ViewModels?
Tips for managing multiple variations of the same application, with regards to project organization, and source control?
Should there be a separate dll for authentication (membership and role providers)?
Any other thoughts? (Sorry for the open ended/loaded question, maybe I should remove this one)
My advice:
Don't try to solve your problems with Source Control. Unless you are
really good with branching/merging and very very disciplined. I'd
recommend one code base that is pulled together with Di/IoC
DI/IoC lots and lots of it - Look at Autofac and the Mutli-tenancy
extra. Keep everything loosely coupled as much as possible
Testing - TDD as everything needs to be loosely coupled lots of testing - look at Autofixture/AutoMoq
Extension points galore - layers of re-direction are your friend as
everyone will want different implemenations. Our core architectural elements
is a CQRS light style - Commands, Command Validators, Queries, and
Domain Events
Keep everyone on the same database structure (unless you go NoSQL
etc)
Use Onion Architecture - Make 3 projects, Web
(MVC5/WebAPI/ViewModels), Infrastructure (all the technical stuff
Repository implemenations etc), Domain Layer
Then make projects per client with overrides - e.g. Custom
ITimeSheetCalculator etc
Include ViewModels in Web Project - Look at per tenant ViewModel
mappings if required. Use AutoMapper
Look at stuff like VirtualPathProvider EmbeddedVirtualPath provider
so you can put views CSS in client DLL
Create an Ambient Configuration file that defines what is turned on per tenant. Feature toggles will be required. Especially during dev for features not yet complete
Find yourself a canary - a client you can work with on a beta version who you trust and can give good feedback
For security look at using Claims Based Identity - comes baked into MVC5. Makes it easier to have different security rules pre tenant etc
If you are working with multiple clients and they all want different
features/or same feature but implemented differently you need get the strongest person you can get to gather requirements. You can't do traditional Scrum and have developers etc and work directly with all the clients. You need someone in your company acting as proxy product owner who will take ownership of the problem of getting all clients to agree on general features
Consider Azure has lots of nice features we have used. Easily allows scale up and down.
Good luck
I am wondering what is the better way to go. I created a webapi project and am currently working on making my api.
In the future I want a full asp.net mvc 4 website and that could also contain forms to insert data into my database.
I am not sure if I should
a)
Make a new area in my web api project and build my website from there.
b)
Keep it in the same area and just make some new controllers and such in the web api project.
c) add a new asp.net mvc 4 project to my web api solution project.
Definitely two projects. In fact, I'd actually recommend three projects:
MVC website
Class library, for sharing your DAL/Service layers
Web API
Your MVC site shouldn't need to query your Web API, that's just going to create HTTP latency that's unnecessary. Both your MVC site and your Web API, are just "frontends" for your class library. They will both reference the class library and interact with the class library.
A Web API is only necessary if you're trying to provide third-party access or you're interfacing with a project in another language. If everything is .NET then just share the DLLs and call it a day.
K. Scott Allen recently wrote a brilliant post on the Coexistence of ASP.NET MVC and WebAPI it covers the most common scenarios and when it's appropriate to use WebAPI with MVC or when you should just use MVC.
I would use that as your guide pick the solution that best meets your current needs. My advice is to keep it simple and if your requirements are simple then there is no reason not keep WebAPI and MVC in the same project - it works just fine. As your requirements change you can always split them up into different projects or solutions, but by then you will know exactly why you are doing so.
http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx
absolutely,
go through link http://efmvc.codeplex.com/
which is the best architecture to develop the big apps
may this one is help you...
another BEST one MVC N-Tier architecture
MVC ---------> WEB API (services)------ > here BL | DL(ORM) | DB)
which you create this in same solution and build the app...
Separate projects for the web api and the web interface will help split things up, but it does cause duplications. We went that way recently and it works well, but it caused a few problems.
Arguments for having a single project :
Since we don't have a domain name yet, we have our API on the 8080 port. We could use a directory binding to make the API accessible from a sub-directory of the web interface but we were worried about production only bugs about absolute path resolution.
Many settings are shared between the two projects so we have to copy them in both web.config files.
Arguments for having multiple projects :
They are easier to upgrade since they can have different dependencies and they can be built totally independently. For example, our API project uses a few more recent versions of some dependencies.
It forces you to extract all of your business logic into a separate library and makes it easier to think about both projects as separate sub-systems.
It is easier to setup the web interface to a separate machine if the load is too much. This is a concern for us, but that may not be your case.
If I had to make this decision again, I probably wouldn't bother with separate projects unless the system was extremely complex and I needed the additional structure. An argument can be made for both options, but I think the deployment headache it brings is not worth it.
I've been working with S#arp Architecture but this can probably be applied to any DDD architecture (Domain / Core, Application Services, Infrastructure, and Presentation).
There are many ASP.NET MVC examples that show the controller operating on the domain model through repository interfaces. In fact, the S#arp Architecture tutorial has the StaffMembersController referencing IStaffMemberRepository where it calls FindAllMatching (implemented in the repository). The StaffMember entity, also in the domain/core layer, looks like a data bag with properties and minimal validation on the properties.
Let's say you have a controller that is getting bloated with things that look like business concerns. After reading Microsoft's "Designing Business Entities" chapter in Microsoft's Application Architecture Guide, I believe these concerns could be called "Domain Services".
I want to put these domain services in the domain/core layer but I'm not sure where they should go. Should I create a services folder in the domain/core project that hosts interfaces with an implementations folder underneath it? That seems like a good approach, but I want to see how others have handled this.
Thanks!
What you're calling Domain Services in your question are what I would call Application Services. This kind of confusion over the three different types of service (application, domain and infrastructure) is what lead to the term "Tasks" being used in Who Can Help Me? (instead of application services).
Broadly speaking, I see domain services as actions/behaviours within the domain that don't belong to any single entity - this is pretty much as described in the Evans DDD book. Application services are more of an orchestration layer/facade over the domain that allows an application to interact with the domain without needing to know the full detail about how it works.
So I believe you need an application services layer to remove the bloat from your controllers. This is the approach that's shown in WCHM and it's the one I now follow in my apps.
In terms of where they should live - I'd send to say you should have them in their own project. If you're being purist about it, the contracts should also live in their own assembly, which means that if you like, you can remove all knowledge of the domain from your controllers. However, the WCHM approach places the contracts in the Domain project, and allows the controllers to have knowledge of the entities. Some people complain about this but it's basically just a compromise.
Hope this helps
Jon
Personally, I'm not a fan of how S#arp Architecture (at least, in their demo projects) has the controllers talk directly to the repositories. My $0.02 is that the domain services should be the interface between controllers and repositories. The repositories exist strictly to abstract away the database (e.g., so that you can replace it with, say, LINQ to Objects during testing). The domain services implement your business logic. You want to be able to test those without connecting to a database, or having to mock out your entire session.
An example that I think gets this right is the MVC project developed in Mark Seeman's book, Dependency Injection in .NET.
We built a real world ecommorce platform based on Sharp Architecture and created a demo project that showcases the architecture we put in place. This added the ViewModels, Mappers & a Task layer which helps separate concerns. This is going to form the core architecture of Sharp Architecture v2.0
See http://whocanhelpme.codeplex.com/ for more details.
I have an architectural question. We have many applications in our company and we are planning to use ASP.NET MVC and Entity Framework in our future projects. The next project that we need to implement is a central authorization/authentication system. There is no option to use an existing one for reasons that doesn't mater right now. This system probably will be structured as a service. What we don't know is: how the other applications will know about "the model" of this authorization/authentication system? I mean, how they will know user, roles, etc. classes? What is the best practice? One of our colleagues suggested to create the entity framework model (.edmx) in a class library. The problem is that in this case we should copy this dll for all projects that will access the authorization/authentication system. Is it a good solution? Does anybody has a better idea?
You can implement your service as a SOAP-based web service, which means your data model and methods will be exposed via SOAP and described using WSDL. The web service can be consumed from any language, without requiring you to distribute any class libraries.
Many languages also have tools which auto-generate client side class wrappers based on WSDL description of your SOAP interface (e.g. wsdl.exe for .NET clients).
Just to add to what DSO already said, the standard way to do this is through the "Add Sevice Reference" dialog box in Visual Studio. It will query your web service, figure out the classes that are needed, and put them in a reference.cs file. You can also use the svcutil.exe (or if you're using Silverlight, SLSvcUtil.exe) to do the same thing. You have to regenerate the reference.cs file every time you change the interface of your web service, but that usually only takes a few seconds.
It's also possible to create a distinct set of Data Transfer Objects that can be shared back-and-forth between the various layers of your application, but unless you have very strong architectural requirements, I've found the auto-generated classes to work reasonably well.
See also this article here about the self-tracking entities available in EF 4.0, if that's an option for you: http://msdn.microsoft.com/en-us/magazine/ee335715.aspx.