Generally projects are created using the below method:
Create a solution with 1 DAL class (this has a dbml file). Create a 2nd class project called BLL which is the business layer that creates the CRUD operations. Finally have a Asp .Net project.
First thing i do is in the DAL (Data Access Layer) i create a connection to the database and drag the required tables.
I create code to get,edit data etc, in the BLL project.
I then have to add a connection string in the Asp .Net project so it can connect to the database.
The issue i always seem to face is when i deploy the project to a test server i can change the Asp .Net projects web.config connection string easily, but at first run the application breaks (cant connect to the sql database) as in the DAL is still looking at the original connection string. So what i have to do is set the new connection string in the DAL project compile and copy that across which then allows everything to work.
I face the same issue when going from the test server to the live server. I've read about using config files but this is as far as i understand they can be used..... But surely there must be an easier way to,change the connection string in one place without having to recompile my DAL dll?
Are there tricks im missing or addons i could use to take advantage of?
If you dont want to use 2 connection string(one in web.config of your UI and the other one on your Data Access) and you dont want to depend of a specific database(in this case SQL Server), you can use just a single connection string on your web.config UI.
When you done that, on your DA, just use the DLL Microsoft.Practices.Enterprise.Data so you will not depend of SQL for connections.
Next time, when you want to migrate your application, for example, from SQL to Oracle, since you are not using anymore SQLConnection, you just change your connection string and its done!. Your migration to Oracle its done in 1 minute.
Related
We have a project for school in which we have to create a web application. We have access to an online database, but the problem is that we have to connect through VPN before we can connect to it.
For this reason, we're looking for a possibility in which we have a local database (which would be in the project, I suppose?) that we can all use (the project is on a subversion server). But when we deploy the project on our deployment server, we want it to use the real database connection.
I think I've seen it before, but after searching for hours I couldn't find anything relevant.
Is this possible?
EDIT:
We use MVC5 with Entity Framework.
People typically do this in one of several ways depending on what you want to achieve.
Pull down the database as an mdf file and store it in your repository. You can then have a manual step during setup where you ask people to import it into their database (I recommend localdb for local development but sure, you can use sql server or something).
Advantages: Very simple to set up for the person arranging this.
Disadvantages: Manual step is difficult for beginners. If the database is large it will swell your repository. If one developer changes the database (for example by adding a column) then you have to let everyone know to blow away their copy and restore from backup. Also, there is no real explicit history of how your database changes and your test database is not integrated with whatever you have to do for deployment.
Pull down the database as an mdf file. Include this file in your project and set it's properties as Content/Copy if Newer. Then use it directly using a connection string to attachDb such as Server=(localdb)\v11.0;AttachDbFilename=.\MyDataFile.mdf;Database=dbname;.
Advantages: No manual step, everything just works
Disadvantages: Obviously you'd want to use relative paths for AttachDbFilename and I'm not 100% that this is supported. Also, same as above but instead of having to let everyone know when their db needs restoration it just restores behind the scenes. This can mean users suddenly see their data disappear with no notice. It can also fail sometimes due to things like a locked database file and everyone just has to get good at keeping an eye out for that.
Maintain a sql script that can recreate your database in localdb. Provide people with a powershell or batch script (also in source control) to run it easily. Optionally use a post-build script that determines if you need to recreate the database and runs it.
Advantages: Everything is very explicit. Reasonably small size in the repository (which should be able to store text efficiently). You can use the same script as part of deployment.
Disadvantages: More work to set up. Still no real way to deploy changes to existing databases.
Use Entity Framework Database first. I can't speak to what the process looks like exactly when doing this but I know that it is possible.
Advantages: I guess.
Disadvantages: Ewwww EF database first
Use Entity Framework Code First with Migrations. Use explicit migrations (not the silly auto-generate-my-entire-db cruft) and write a proper Seed method to populate your data.
Advantages: This is what professional developers do and is based on tested patterns used frequently by Rails, Django, and many other frameworks. It is very flexible and explicit and supports changing existing databases.
Disadvantages: Can be quite difficult to set up if you don't have experience and especially if you're unaware of the migrations pattern. There's some naming difficulties that make it kind of hard to google (database first EF vs code-first EF, explicit migrations vs auto-generate-the-db, several different Seed methods that depend on your initializer).
You can create a local database using Entity Framework, which saves the database file on the local filesystem, which you can push to your version control server to share with your colleagues. If you decide to deploy the database, you can generate an sql script that you can run on the production database. You can do so by connecting to the local database using SQL Management Studio. You will just need to modify the connection string of the published application after deployment.
You used to be able to use Sql Server Express but it has changed to LocalDB and can be installed and run locally.
http://blogs.msdn.com/b/sqlexpress/archive/2011/07/12/introducing-localdb-a-better-sql-express.aspx
https://msdn.microsoft.com/en-us/library/ms233763.aspx
I recently started to get into EntityFramework in order to map my model automatically into a MySql database. So I read some tutorials and started tests to validate them. Everything works fine, as far as I only have one project. If I separate the solution some problems arise. In order to demonstrate this, I set up a console project (lets call it A)with EF6.1 that saves all my data to the database. Everything works fine. If I now create a second console project (lets call it B) and and use the DbContext through a IRepository-Wrapper (from A) some problems occur:
First of all, I have to put my config data for the database and EF config into the App.config of project B. I don't like this, but I can live with this.
Furthermore the application compiles, but throws a exception, as long as I don't reference EntityFramework.SqlServer in project B.
In order to separate the concerns I don't want project B be to know that the data is stored via EF in a database. Or to give a real world example I don't want that my WPF Gui knows, that the data came from a database.
Is there a workaround for these problems? Did I miss something, or do I have to live with that problem when using EF?
For the first problem, you're not forced to put your connection string in the assembly's config file. You can use whatever you like (your own config/ini file, the registry, etc.), and then pass the connection string to the DbContext(connectionString) constructor.
As for the second issue, this seems to depend on how you are abstracting the database. If it is a complete abstraction, then it shouldn't leak any dependencies on EntityFramework.SqlServer. On the other hand, Entity Framework itself already follows the repository design pattern, so I'm not so sure if you need to add another layer on top of it. If you do want to continue with creating a database abstraction layer, consider putting it in a third library project that the other user-facing application projects reference.
I am currently developing some application in C# and I am using a n-tier architecture and embedded database SQL Server Compact. SQL Server Compact is pretty new to me, and I have some problem with connection string to this database. My n-tier application consists from DataTier, MiddleTier, PresentationTier. Every layer is separate project in solution.
DataTier contains the db file db.sdf and files for EF 5.0 including entities. Model was created with a database-first approach.
I had idea that I can build this embedded database directly into dataTier.dll and reference to it from other layers but I don't want to make connection string absolute, so I currently using connection string in this form:
Data Source = |DataDirectory|\db.sdf
in every layer, which is nonsense cause it creates separate database for each layer, but I can not find out how to make connection string relatively to database in dataTier. Is that even possible?
Could you point me to right direction or what is best approach to this problem?
Thanks
I made an application that generates reports based on data from a database.
The functionality of my application is correct, but I have a following problem: my client has 2 identical databases - one for testing and one for actual work he does.
My application should work with both databases (it should have a "switching mechanism"), but I don't know how to implement it.
I know that I could just switch between connection strings but the problem is that in my reports I use datasets that are bound to one database.
Is it possible to fill those datasets with the data from both databases (since the databases are identical in schema, it should be possible), and how would that be done, or do I have to use duplicate dataset/report pairs?
I'm using C# in VS 2010 with SQL Server 2005, and .rdlc for my reports.
Thanks.
Ideally you should should be able to change the connection string in one place and it should affect project-wide.
This will work ONLY IF you get the connection string from one place. Keep it in the app.config file.
See this article to see how you can store and read the connection string from the app.config file.
You've hit upon the reason why people implement the Repository pattern or at least a version of it.
You really need to remove your business logic away from the database, so that it is database agnostic. It shouldn't care where the data comes from only what it is.
From what you' said the implication is that your client doesn't wants more than just a change in the app.config connection string used for database access.
If that is so then, I know that it will entail some work, your best bet is to have a singleton pattern type class to control all data access to and from your data layer.
Using a known inteface you can use a factory pattern to create access to your development or live database at runtime (perhaps based on an app.config setting or even a test class that has no database access at all, but just returns hard coded test data.
I have probably written the same LINQ to SQL statement 4-5 times across multiple projects. I don't even want to have to paste it. We use DBML files combined with Repository classes. I would like to share the same Library across multiple projects, but I also want to easily update it and ensure it doesn't break any of the projects. What is a good way to do this? It is OK if I have to change my approach, I do not need to be married to LINQ to SQL and DBML.
We have both console apps and MVC web apps accessing the database with their own flavor of the DBML, and there have been times when a major DB update has broken them.
Also, since currently each project accesses the DB from itself, which is sometimes on another server, etc. Would it be possible to eliminate the DB layer from being within each project all together? It might help the problem above and be better for security and data integrity if I could manage all the database access through a centralized application that my other applications could use directly rather than calling the database directly.
Any ideas?
The way I handle this is using WCF Data Services. I have my data models and services in one project and host this on IIS. My other projects (whatever they may be) simply add a service reference to the URI and then access data it needs over the wire. My database stuff happens all on the service, my individual projects don't touch the database at all - they don't even know a database exists.
It's working out pretty well but there are a few "gotchas" with WCF. You can even create "WebGet" methods to expose commonly used methods via the service.
Let me know if you want to see some example code :-)