Following is the architecture of my MVC application that is built using WCF service and EF:
MVC application >> WCF Service >> Business Logic Layer >> Data access layer >> Data Store
I have created MyDbContext in Data Access layer, and it's interacting with the database.
I have created a connection string in web.config file of MVC application with the name MyDbContext. I believe this should work, but instead it is trying to create a new database on my sql server. What can be the reason? Or if I am missing anything?
If I put the connection string in web.config of WCF service, it works fine. but I believe this should be part of MVC application only, and WCF shouldn't be limited to using this connectionstring only.
If you are using WCF service to access business layer and data access layer your ASP.NET MVC application should not access the database directly - it should even don't know about database existence at all. That is the reason why you are using WCF service, isn't it? Otherwise you can delete whole your WCF service layer and call the business layer directly from ASP.NET MVC.
Connection string is not automatically transferred from MVC application through WCF call. The correct solution is to define connection string in WCF application because it is the tier where the database is accessed.
Since the WCF service is hosted in the same container which is also hosting the data access layer then it is entirely reasonable to configure it with the correct connection string.
Why would you not want to do this?
Related
I'm building a system which will use a web layer (ASP.NET MVC) to connect to a service layer which has multiple WCF services hosted in a windows service.
User will login once to the web layer. Then, according to the function he called, a connection will be made to WCF services. I need to use same user in each service for authorizing user, auditing and logging.
What is the best practice for this? Should I save credentials in Session and each time I need to connect to WCF service and pass those credentials to it?
All,
I have a ASP.NET Web API project that is making a REST call to my service layer in another project. The service project's data access is via Entity Framework 4.3. The connection string in the web.config files is set to use Integrated Security.
What is happening is, the name of the server, "server A", is being passed to the service layer, and failing authentication against SQL Server. There isn't a user account named "server A."
More specifically this is what the architecture looks like
jquery file making an api controller via POST to a method within the API controller
API controller method references the service layer DLL, and calls a method within the service class
The service class is calling a method in a repository class that uses DbContext to connect to SQl Server 2008 table.
Is there something specific I need to be doing when using the Web API framework in order to pass the correct user name down to EF?
Any help would be appreciated.
Derek
The problem is double hop impersonation. You can read about it by this link.
But i'm not sure that such impersonation is possible via REST. I recommend you use database via special account, not integrated security.
I've got one class library project that contains an EF model that points to a SQL Azure database. I also have another Azure WCF Web Role project that contains a WCF Data Service exposing the data in my SQL Azure DB as a OData service. Right now I have the connection string stored in the web.config of the WCF Web Role project.
What I'd like to do is make this a configuration, so move it over to the service configuration files so I can change the connection string if necessary (putting it in the web.config seems shortsighted).
The problem I'm having is how to wire the OData service up to not use the web.config connection string but instead use one from the configuration.
RoleEnvironment.GetConfigurationSettingValue(NameofSetting);
???
I wanted to get some peoples opinions on adding a web serivce layer. At my work, we want to start using web services to handle some of our operations.
Our current project structure that we follow for our ASP.NET MVC apps:
MVC App (View/Controller/ViewModel/Service Layer) --> BAL (Business Access Layer) --> DAL (Data Access Layer)
The MVC app, BAL, and DAL are separate assemblies.
There is a Domain (model) assembly as well that is shared among the MVC/BAL/DAL layers.
The plan is to create a web service that will handle all security functions. This web service will be used by multiple web applications. When we make changes to the Security Web service we only want to modify code in one place and not every web app. So I'd prefer if the MVC project has nothing in it that is tied to a web service.
So I was thinking of adding a Web Service Layer between the BAL and DAL layers.
So something like this:
MVC project (View/Controller/View Model/Service Layer)
calls
BAL Layer (Handles caching / DB Transactions)
calls
Web Service Layer
calls
DAL Layer
What are your opinions?
A couple thoughts.
You are putting your web service layer between you BAL and DAL. This means everything will need to go through your web service, including functions which aren't related to security. I think this is adding an additional layer of complexity. If multiple websites are using the web service, create it as a stand along application/service. Then you can call the service from the different layers of your application depending on what layer needs the service. Generally you would create a Webservice wrapper with a clean interface so you can easily call the Web Service from your any layer in your application.
For the sake of discussion, lets say your web service handled validation of login and password of a user. You can connect to your webservice wrapper directly in your MVC project to see if the user data is valid, then you can log them in if it is. Later, if the user performs a function, and the business layer needs to check if the user has permissions, that layer can use the api wrapper which calls the api to see if user has permissions, and so on.
MVC APP
/ \
BAL --> Web Service Wrapper
/ \
DAL WCF WEB SERVICE
As someone who supports an application that is ridiculously layered as so.
GUI
BAL
DAL to WebService
Webservice
WebBAL
WebDAL
I would suggest putting your GUI as close to your webservice as possible.
so I'm developing a SAAS application using asp.net mvc SQL server 2008 and Linq2SQL I've a master db where I'll store information about clients like name subdomain/hostname information and other stuff and I'll use one database per client for the actual client data,
what is the best way to generate and use the connection string for each individual db the connection string will be based on each customer domain so I could hard code it into master db at customer creation and create the DataContext based on that? any flaws in this strategy?
I am also using forms authentication and it will be built into each clients own db so do I've add anything dynamically to the configuration? as currently the authentication/membership is driven by connection string inside the web.config file
You should probably have a table in a centralized master db that includes the database connection information for each client. Then in your SAAS application, any time you are instantiating the data context, instead of using the default parameterless constructor, use the constructor overload that takes the connection string you stored in the centralized database for that client. The context shouldn't be kept alive between requests, so you shouldn't have a problem with cross page requests across multiple clients.