I am launching my startup and i need to make a critical architecture choice.
I will provide a SAAS web application for my clients, they have different specific needs but the main purpose of the program is the same, automatically generating documents and pdf.
Technincally i choose ASP.NET MVC, WebAPI, EF Code First. Now I have a working proof of concept with only one project (1 db, 1 asp.net mvc client, 1 asp.net webapi, 1service layer + 1 repository)
I will have one database for every client (easier to maintain, scale ...)
One WebFront for each client with personalized html/css templates and of course specific data/menu
Only one WebApi service exposing all services for each client,
For example /api/client1/, /api/client2/ with almost the same api calls but not the same data returned.
For each client a service layer (Class library dll) that stores business logic, data acess, POCO/DTO.
Each Webfront shares reference to specific service DTO/POCO.
I need of course my solution to scale horizontally, not vertically.
So is it a good choice?
Do you have any recommendation/better solution ?
Can I put All this in the same visual project ?
I really would like to have the service layer(business) in only one project, and with good Object Oriented approach I can serve all my clients with common needs shared between all of them and specific one in derived objects.
Thanks for help
Related
I need a suggestion: I currently have an ASP.NET web forms application (pretty large scale) with three tier architecture and ado.net for database communication.
Application structure is
Web > BLL > DAL > BO,
BLL for business logic and DAL for database interaction using ado.net (stored procedures).
There are other 4 apps connecting with BLL that make applications tightly coupled. Now I have to redesign one application so we decided to change underlying technology.
And I currently have few options:
Change front end layer and rewrite complete app to Angular and have API layer on BLL (most time consuming and complex solution I guess)
Change font end to ASP.NET MVC and directly call BLL from controller (we can reuse existing html mostly, but app will remain tightly couple and still monolithic)
Change front end to ASP.NET MVC and write API layer on BLL and connect controller to BLL via API (not a good idea to add an extra http request for every sever call client > controller (server) > API ( server).
Please suggest any alternative approach. Is this good option to rewrite complete complex application from ASP.NET MVC to Angular?
I would suggest using ASPT.NET CORE WebAPP and one or more ASP.NET CORE Web API, REST, microservices, so you don´t need to expose your services on the web and would be better to maintain it and for huge systems. Used of EF core, with CQRS pattern, is a very good choice within your WEB API so you can implement your BLL on it. Try to use to SOLID principles, mostly the D, dependency of inversion, that has already a built in IOC container so you apply the dependency of injection on it. Don´t forget to secure the system with authorization and authentication. OAuth 2 is a good way to go!
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
I have a large vb6/sql database app (hundreds of tables, classes, and forms) that I want to migrate to c#, with both web, phonegap, and winform clients. There is a lot of database and business logic that I want to centralize, and since I prefer ASP.Net MVC as my web UI platform, I'm considering the following:
MVC Web project to include:
MVC Web controllers and views for web UI
MVC controllers to serve JSON objects to phonegap apps and rich html pages
Service classes to provide BLL services to MVC controllers
DAL classes to provide persistence and POCO objects for use by service/BLL classes
Webservices that expose Service classes to Winform apps. They would accept and return POCO objects
The Winform app will rely heavily on the Webservices for all of it's data. Since I have hundreds of database tables, the webservices will be returning this data to clients as POCO objects (some nested, some Lists of POCO objects). I'm worried that 1) the WSDL will be huge, and that as the app grows and the number of classes exposed grows, it will become unruly (will VS choke?), 2) returning POCO objects through a webservice may not perform well. I am used to calling SQL server directly from my winform UI, so the prospect of going through a webservice seems like it could become a bottleneck since everything gets serialized and goes through IIS.
Btw, I know the service layer is logically separate from the MVC UI layer, but I've combined them to make deployment simpler. I'd also consider WCF if it solved any problem, but as far as I can tell, it adds unnecessary complexity.
Are these valid concerns? Do you have any other advice?
How are you building the services that the WinForms consume? Depending on how things are setup, you may want to reconsider WCF. You could put the BLL in a WCF service. Then your MVC application, WinForms and PhoneGap application can all use the WCF service which means there is a single location for all of your business logic. As long as you're not dealing with gigantic POCOs and you're making async calls, you shouldn't have any major performance problems with your WinForms apps using a service.
WCF could be very nice here due to being able to easily expose different endpoints based on the clients you'll have connecting. Your MVC and WinForms app could use a binary interface for example, while your PhoneGap application could leverage a REST endpoint.
If you are worried about your service becoming too big, you could also consider breaking it up into multiple services, each which operates on certain parts of the database, or some other logical separation which may already exist in your BLL.
I also wonder why a WinForms app is necessary at this point. Is there something you cannot do on a website? Have you looked into WPF or Silverlight? Both work quite naturally with services.
I would appreciate if someone can provide some insight into which one is more beneficial.
RESTful service in WCF can provide the same functionaly as ASP.Net MVC Controller, i.e URLS can be formed appropriately using Controller/Action.
Is there real benefit of using one over the other.
WCF Rest service will provide..
1) Cert Authentication out of the box
2) Logging
3) Message Headers etc
MVC
1) Different Action Results out of the box
If someone has used or debated these two technologies . please let me know
UPDATE:
I went ahead with the MVC Model as it gives me lot of flexibility and I can use the same action to render different views with CustomActionInvoker, which is really cool!!!
-RN
WCF makes your service more manageable and offers more protocol options like TCP, Named Pipes, PerChannel, and MSMQ.
WCF gives you the ability to specify multiple methods of binding to the service through the web.config including restful urls, giving you greater flexibility. In conrast, mvc provides you with the ability to easily construct resful urls and output data via code in much the same way as you do a web application, which is really easy and requires minimal additional knowledge if you already know mvc.
My recommendation would be to go with wcf if the service is really important to the overall solution, likely to be called in a different or many ways or has or is likely to have special security requirements.
On the other hand I would go mvc if this is meant to be a quick and simple isolated solution or perhaps is just providing a different representation of data being output in an existing .net mvc application.
At this point in time, your best option is ASP.NET MVC. It provides cleaner access to the HTTP primitives you need to be able to design RESTful solutions.
The only significant advantages of WCF Rest is the ability to self-host the service and if you want to use ADO.NET Data Services to deliver OData/Atom services, then obviously WCF is your best choice.
I'm developing a web app. This is more of a line-of-business app rather than a web site. I'm using ASP.NET MVC, SQL Server 2008, and I've purchased LLBLGen. I need to provide an some sort of API to third parties. For instance, if this was a medical app, third parties might need to CRUD patients, retrieve complex reports, engage certain kinds of workflows, etc.
What is the best way to do this with MVC without going to the architecture astronaut route. Do I need a whole "web service" type layer or can I re-use my controllers in MVC? Does it make sense to have this kind of API exposed through MVC? Optimally, I need a solution that involves the least amount of code repitition. I've found some stuff on doing REST with MVC but some of it is rather ambiguous and I'm not sure if it makes sense. I need a reasonable API but I'm not required to follow all the tenets of the REST religion or anything like that. I just need some sort of API in addition to providing the HTML front-end to the site, be it REST, SOAP, whatever.
Also, what are some options for dealing with URLs? Not everything in the app maps to something like site/products/product-id. Some of it involves engaging complex workflows, etc.
If you're going to have a web site and a web service then I would consider separating the data access and entities layers out from the MVC.
That way, your web service can do the same things that your website can. I would have a service layer that they both interact with. After which point the calls then go to the database and return the objects, and neither the web service nor the website should be able to interact with this layer.
This concept is also known as Separation of Concerns.
You can't/shouldn't reuse your MVC controllers in your web service. If they're so alike that they're indistinguishable, then consider writing your website to be a client of the web service, rather than being part of the same solution.