I have a project which is a single solution in VS2010, and I wanted to have it such that:
Solution one: Admin
Solution Two: Front end
Solution three: Models
The reason for this is that Admin will sit in it's own app pool and the front end will sit in another app pool. We then have model talk to both and under model is the SQL database.
my question is:
How do I set this up in to three separate projects such that models can talk to Admin, Front end and the database?
For what you describe I think you'd be better off keeping one Solution and having multiple projects under it.
You can deploy the results of building the Admin project to one web site and the results of building the Front End project to another web site.
Each of these would reference the Models project. Models don't normally 'talk to' other projects but are referenced by them because the initiating action is coming from a web page request to either site - that's what's controlling the flow.
Often you'd also have another project which is a background service which may also reference your models project. This project would run as an NT Service providing time-based execution of work items that aren't tied to an incoming web request, for example, sending emails.
A further level of complexity would be to introduce a services layer and Data Transfer Objects (DTOs). You background service and all web sites now call into the services layer and interact only with DTOs while the service layer uses model objects to communicate with the database. You can now evolve your database schema independently from your web applications provided the service contract remains the same.
Related
I'm managing a very large enterprise application in that I've implemented microservice architecture. Standalone microservices have been created based on business entities & operations.
For example,
User Operations Service
Product Operations Service
Finance Operations Service
Please note that each service implemented using an n-tier architecture with WCF. i.e have separate tiers(which is independently deployable to separate server) for business and data access.
There is a centralized database which is accessed by all the microservices. There are a couple of common entities like 'user' accessed by all the services, so we have redundant database calls in multiple services. More efforts required due to database access from many places(i.e a column rename requires deployment of all the apps)
To reduce & optimize code, I'm planning to create separate microservice and move all the database operations into it. i.e services can call "Database Operations Service" for any database operations like add/update/select.
I want to know if there are any hidden challenges that I'm not aware of. Whether should I go with this thought? What can I consider as improvements in this concept?
I'm planning to create separate microservice and move all the database operations into it
That's how you will lose all benefits from microservice architecture. One service is down — the whole application is down. Unless you have replication on several nodes.
If your app does not work if one service went down(not implying that it's that service that connects to database), then it's still bad architecture and you are not using benefits of microservice architecture.
Correct for of communication would be if service would have their own databases. Or at least that every service that wants, for example, entity User, will not fetch it from DB, but will fetch it from appropriate service. And that appropriate service could fetch it from common DB at the beginning.
Next step (improvement) in the process of accommodation to microservice architecture would be creation of separate databases for each service. And by “separate” I mean that temporal fault of one service or temporal fault of one database will allow the rest of the app to be alive and functioning.
Generally, there are no hidden challenges in your approach. It just does not give any benefits, as an intermediate form between monolith application and microservice-based.
I am very new to the MVC frame work and ASP.NET WEB API
I have been Building Web Application using ASP.NET AJAX with n-tier architecture with data as Stored Procedure Only for quite some time.
We are trying to upgrade one of our Products to develop using HTML5 ASP.NET WEB API and We would like to keep our DAL and stored Procedures intact and add a service Layer using ASP.NET WEB API or WCF Data Services on top of the DAL and HTML5 Presentation layer will hit the service layer for the data.
can you suggest if this is a possible scenario where we want to keep the database stored Procedures and DAL intact?
As I have noticed the support for Stored Procedures in EF5 needs a lot more maturity to support some of our stored Procedures with multi table datasets I know there are workarounds on this. I have seen EF 6 Alpha Specifications and I am excited about the features.
Does any one have a link to a tutorial or a sample of ASP.NET WEB API Service layer on top of a Data Access Layer? OR can you make some suggestions or point me to right direction please
If I have to make a wild guess on how I want to implement a solution for our current problem. I would say.
Present DAL gives us Dataset and wrapper for DataTable in the dataset to Convert to IQueryable and use them in ServiceLayer skip the whole EF workarounds.
thanks in advance
In reality you could to this. You could place your service logic into Web API, however, I wouldn't do this. I would rather add one more layer of abstraction in order to keep the API as lightweight and as simple as possible. According to your scenario you have something like this:
Back-end DB Server with Stored Procedures
Data Access Layer component for working with number 1, back-end DB.
Now you want to build API on top of 2. My suggestion to you would be to add Service layer (aka Business Logic layer) where you would put additional logic like calculations, if necessary additional validation, messaging services, etc.
And then on top of the service layer I would add Web API. So at the end your layering could be something like this:
Back-end DB Server with Stored Procedures
Data Access Layer component for working with number 1, back-end DB.
Service Layer (Business Logic)
ASP.NET Web API
HTML5 Client
The idea behind this is that sometime again in the future, when you need to add additional features to your product, you would do it in the service layer. Don't go on and add complexity to your Web API. Think about maintenance, testing and future expansion.
I need some advice on how to go about developing the model for a Client/Server system using UML.
In a short explanation the system consists of a Mobile client which runs on mobile phones. As is common with most mobile applications, the mobile application connects to a server in order to carry out some processing, logging for backups, and connectivity to third-party applications.
Where I need an advice is that envisaging the whole system, almost all the classes in the mobile application are replicated in the server application with the exceptions of a few classes. Likewise in the Server application which contains most of the same classes in the mobile application except some others and some extra functionality.
Giving an example, the Mobile application has a User class that consists of the actors personal details and login details. Likewise the Server application has a User class with the same members existing in the Mobile applications User class except that it has some functionality/methods that are not in the mobile application.
The Server application also has a class that connects to a third-party application to carry out its billing functionality/method. This class obviously is replicated in the Mobile application too however without the Mobile applications billing class having the functionality/method to connect to the third-party.
Ok to the issue on hand, I feel if I am going to follow the principles of UML modeling, I should not replicate these classes but rather should make use of Reuse in the modeling. As I am making use of packages to separate the Mobile application from the Server application, I guess it would involve:
Having the basic classes that do the same thing (methods & members) in both the mobile & server applications
For classes with extra members & functionality in any of the mobile or Server applications, I should use inheritance dependencies to build extra classes to take care of them.
Using << includes >> dependency to add classes generated from #2 to the Mobile and Server packages OR using << includes >> dependency to add classes generated from #1 to the mobile and Server packages as the case may be necessary.
Please is my line of thought correct on how to implement the modeling as I feel replicating the same classes would be against the ideals of UML modeling. Yet the fact that their is a separation between the mobile and Server application sort of wants me to think along the line of modeling totally seperately for the mobile application and then modeling seperately for the Server application.
Again, please is my line of thought correct.
It seems to me you just have one model with three packages:
a commonComponents package containing the classes which are used in the mobile and server application
a mobile package containing the classes used in the mobile application
a server package containing the classes used in the server application
the mobile and server packages import (<> relationship) the elements contained in the commonComponents package. For instance the User commonComponents:User class is imported in the server package where it is extended by the serve:User class. Note that as packages are namespace you can have classes with the same name.
I hope this might help you
http://lowcoupling.com/post/47802411601/uml-diagrams-and-models-with-papyrus
My application contains 25 C# projects, these projects are divided into 5 solutions.
Now I want to migrate these projects to run under Windows Azure, I realized that I should create one solution that contains all my web roles and worker roles.
Is this the correct way to do so, or still I can divide my projects into several solution.
The Projects are as shown below:
One Web application.
5 Windows Services.
The others are all class libraries.
Great answers by others. Let me add a bit more about one vs. many hosted services: If the Web and Worker roles need to interact directly (e.g. via TCP connection from Web role instance to a specific worker role instance), then those roles really should be placed in the same hosted service. External to the deployment, your hosted service listeners (web, wcf, etc.) are accessed by IP+Port; you cannot access a specific instance unless you also enable Azure Connect (VPN).
If your Web and Worker roles interact via Azure Queues or Service Bus, then have the option of deploying them to separate hosted services and still have the ability to communicate between them.
The most important question is: How many of these 25 projects are actual WebSites/Web Applications or Windows Services, and how many of them are just Class Libraries.
For the Class Libraries, you do not have to convert anything.
Now for the Cloud project(s). You have to decide how many hosted services you will create. You can read my blog post to get familiar with terms like "Hosted Service", "Role", "Role Instance", if you need to.
Once you decided your cloud structure - the number of hosted services and roles per each service, you can create a new solution for each hosted service.
You can also decide that you can host multiple web sites into a single WebRole, which is totally supported and possible, since WebRoles run in full IIS environment since SDK 1.3. You read more about hosting multiple web sites in single web role here and here, and even use the Windows Azure Accelerator for Web Roles.
If you have multiple windows services, or a background worker processes, you can combine them into a single Worker Role, or define a worker role for each separate worker process should you desire separate elasticity for each process, or your worker require a lot of computing power and memory.
UPDATE with regards to question update:
So, the Web Application is clear - it goes to one Web Role. Now for the Windows Services. There are two main considerations that you have to answer in order to find whether to put them into a single or more worker roles:
Does any of your Windows Services require excessive resources (i.e. a lot of computing power, or
lot of RAM)?
Does any of your Windows Services require independent scale?
If the answer for any of the questions is "yes", then put this Windows Service in a single Worker Role. Put all the Windows Services that the answer for both questions is "no" in a single Worker Role. That means that you will scale all of them or none of them (by manipulating the number of instances).
As for Cloud Service (or the Hosted Service), it is up to you to decide whether to use a single cloud service to deploy all the roles (Web and Workers) or use one Hosted service to deploy the Web Role and another one to deploy the Worker Roles. There is absolutelly no difference from billing prospective. You will still have your Web Role and Worker Role(s), and you will be charged based on instances count and data traffic. And you can independently scale any role (change the number of instances for a particular role) regardless of its deployment (within the same hosted service, or another hosted service).
At the end I suggest that you have single solution per Hosted Service (Cloud Project). So if you decide to have the Web Role and Worker Roles into a single Hosted Service, than you will have a single solution. If you have two Hosted Services (Cloud Projects), you will have two solutions.
Hope this helps.
You are correct ! and all projects goes to under 1 hosted service if you create only one cloud project for all your webrole and worker role project
Still you can divide your projects into several solution and you have to create that much cloud project and hosted service on azure platform
You can do both.
You can keep your 5 separate solutions as they are. Then, create a new solution that contains all 25 projects.
Which solution you choose to contain your Cloud (ccproj) project(s) will depend on how you want to distribute your application.
Each CCPROJ corresponds to 1 hosted service. So you could put all of your webs and workers into a single hosted service. Or you could have each web role as a different hosted service, and all of your worker roles together on another hosted service. Or you could do a combination of these. A definitive answer would require more information about your application, but in VS, a project can belong to more than 1 solution.
I'm researching some Windows Azure stuff, in order to make a decision whether to move to Azure or not.
Basic information
To answer the question, you'll need some basic understanding of my app so here goes.
The app is an ASP.NET MVC 3 application that connects to a SQL Server database.
It is a single instance application, meaning that every customer eventually has their own instance of the app running on our server, deployed to IIS 7 as a website.
I have one SQL Server, where each instance has its own database.
I also have a set of Windows Services to do some background processing. That should be straight forward, as I'll just rewrite those to use a Worker Role in Windows Azure - most of the logic in the services is located in their own class (library) anyway, so the service it self just calls one or more methods in a class.
Now to the question
Whenever someone signs up for a free trial, I add a record to an Admin database I have.
I then have a Windows Service that deploys a new instance of the ASP.NET MVC 3 app to IIS, grants permission to a few folders, runs the database deployment script and updates the record to reflect that it has now been deployed, and finally sends an e-mail to the prospect that their free trial has been created - here's how you access it.
So, how can I deploy a new instance in Windows Azure from a Worker Role? Preferably, I'd just add a new website to an existing Azure instance and create a new SQL Azure database for that particular site to use.
Does this require a lot of work to set up? Is it even possible?
Based on two quotes, I would like to suggest calling this a multi-tenant application:
It is a single instance application, meaning that every customer eventually has their own instance of the app running on our server,
And...
a Windows Service that deploys a new instance of the ASP.NET MVC 3 app to IIS, grants permission to a few folders
If I understand correctly, there is "one" IIS server (well, in Windows Azure, it's one Web Role, scalable to multiple instances), and with each new "tenant", you set up some new stuff to support that tenant.
If that's indeed the case, you can definitely do this from a worker role - just look at Nate Totten's multi-tenant web role blog post and related code. Look at the webdeploy code that actually manipulates IIS.
Further: take a look at Cloud Ninja, a project a few of my teammates published along with Fullscale180. This is a multi-tenant app that demonstrates how to manage multiple customers in a single deployment, as well as monitoring and scaling.
Finally: should you need to actually create brand new service hosts and storage accounts, the latest updates to the Windows Azure Management API support this.
I hope that helps a bit...
I think most of the things you want to achieve are possible.
It will definitely require some work to setup!
For some ideas on how to achieve what you are looking for, take a look at the MS SaaS example - http://www.fabrikamshipping.com/ - especially designed for porting existing apps to SaaS on Azure. Inside this app they have an "onboarding process" - and that process includes setting up new SQL connections and new portals.
There's lots of good blogging (watch the video) about this on http://blogs.msdn.com/b/vbertocci/archive/2010/10/07/new-online-demo-introducing-fabrikamshipping-saas.aspx