I'd like to know the best architecture.
We have a web application running different domains. Each domain has its own MySQL database but the db structure is the same for all of them.
We have a web application for the visible part of the application.
We have a dataLogic project
We have a dataEntities project
We have a dataAccess that contains only the methods to connect to the data base.
Before we called stored procedures on a database. But we had to change it because the performance was bad. Also, the problem was that every change we made we had in a stored procedure we had to copy to every database.
We are thinking in using a WebService to retrieve the data. Every domain can call the web service with a connection string and connect its database to retrieve data. This way when we change a SQL query we only have to compile the webService and change it, we don't have to change versions on multiples domains.
Also, what do you think about the SQL queries? Since we don't want to keep using stored procedures, what is the best way to do it? Directly from code?
Thanks
T
If you have multiple Database servers you will have to make Structural changes from one DB to another one way or another. There are many tools to change Database structures. These tools will look for differences between Schema, and will either generate the SQL code for you, or do the changes by itself (it depends a lot in the tool, there are powerful ones and not so powerful ones). Please do take a look at Toad for MySql. Now, for the Data changes, you may want to replicate the data from one Database to another. This is done through Replication.
We are thinking in using a WebService to retrieve the data. Every
domain can call the web service with a connection string and connect
its database to retrieve data.
This sounds like a good idea and since you already have "dataAccess" and "dataLogic" projects, it should not be too hard to make the services.
Also, what do you think about the SQL queries? Since we don't want to
keep using stored procedures, what is the best way to do it? Directly
from code?
I don't think it is a good practice to have the SQL queries directly into your code, but it depends in a lot of things, so I would suggest Stored Procedure vs Hard-Coding the queries, or LinQ (Entity Framework 4.1).
Good luck with your project and I will take a look at this thread frequently to see what you end up doing.
Have fun!
Hanlet
Related
In my new work, they have two ASP.net projects. Both projects are using the same MS SQL Database. Each project has a different developing team and end users. And each project has its own tables, and there are a common tables which both projects reads/writes data, and sometimes they use this common tables to send information to each other. i.e one system insert record, the other system update a flag in this record which means 'Yeah I can see it', and update some fields, then the first system catch the data ... etc.
My first question: Is this a good design, what are the disadvantages ?
In the other hand my opinion to split the database into two databases, one for each project, and make communications between them be through web services.
My second question: which approach is the best practice, and why ?
I do not think there is any problem of having two different projects sharing a common database.
Instead of splitting database into two separate databases , I would suggest have single database only and create a third separate WCF project.
This WCF project will have only one purpose that is act as database layer , so all the database queries will be written in that service and asp.net projects will consume it.
Advantage of this approach is that all the queries will be centralized and there will not be any duplication of queries.Also in future if any new Module comes in the system like desktop application or Mobile application then there is no need to put large efforts in database queries.
Same queries can be used in all places, so maintenance will be simpler.
I don't think there is any problem with having a database common for two projects.I mean, even in a single project, there are so many users updating the same table at the same time.
don't see major drawbacks to the approach. Personally i would prefer database table prefixing like
project1_sometbale
project2_sometable
common_sometbale
I'm developing an application in asp.Net using VB and an Access database. My client has specified these, and I can't use more robust tools.
My application has to perform a sizable number of logical operations, and SQL is perfect for this. However, because of some of the limitations of Access SQL, I can't really write large SQL statements that do the whole job. Lacking logic testing like IF-ELSE, I'm stuck writing literally dozens of SQL statements. That would be OK, but I'm leery of all that activity against an Access database. Access isn't very stable when you work it that hard.
I've fooled around with funky solutions using things like the SWITCH function, but they look more like spaghetti than actual code. Wouldn't be maintainable at all.
I can upload all of the data into objects in memory and loop back and forth through them using VB logic, but SQL would sure be more efficient.
My question is: is there some object I can create in memory that I can run SQL against? Some recordset-kind of thing? Came up snake-eyes when I searched for this, but I thought I'd ask.
Thanks for any suggestions.
So if I understand your question correctly you currently have to use an Access database as the backend storage but you do not like doing this and would rather pull all data into the application (ASP.Net) and perform your queries against this as if the database was an SQL database in the application. I expect then that you would push the data back.
AFAIK no this cannot be done. While you could put most of the data into objects and do the manipulation there you will not have the relationships etc. but you could try using LINQ or entity framework.
This link below explains that you can do LINQ with MSAccess and that may give you the query power you want.
Query Microsoft Access MDB Database using LINQ and C#
I am developing an asp.net application ,, currently i'm using Sql Server 2008 as backend.
However i have been asked to develop one application with multiple databases (oracle,sql server,mysql etc). Is it possible to achieve this.Is it a feasible solution.What may be the possible disadvantages associated with it.
Thanks
This should be feasible, but it might not be easy.
You'll need a Data Access Layer that insulates you from the details of each database, as each database will have slightly different syntax in it's language, meaning you (probably) won't be able to write one query that'll work across them all. You haven't said what the domain of your system is, but in, let's say, a bookshop your DAL would have methods like GetBooks, GetBook, GetCustomer etc.
Underneath your DAL you'll probably then have a set of different .NET assemblies, each of which knows how to run your queries against one database (SQL Server, Oracle etc). When one of the methods in your DAL is called, your DAL passes that onto the appropriate assembly to actually make the call and return the results to your application back through the DAL. Your DAL will need to be able to create instances of the classes in the assemblies, there's a few different ways to do this but I would suggest MEF as being probably the most straightforward.
Disadvantages:
Because you need to be generic, it's unlikely you'll be able to use
a particular feature of any one database
It'll take longer because for each feature you develop, you need to write the code in the DAL for it, and then write the code for each separate database assembly, plus any SQL coding in the database itself, and then test it for each database.
Another approach to solve this problem would be to use the SQL Server as the layer that ties together the different databases. SQL Server 2005 and later have a feature called Linked Servers. This will let you link to other database.
This approach will allow you to model you datalayer as if it was one database and let SQL Server abstract the complexities of the multiple databases.
You can also look at the SQL Server feature called OPENROWSET. This will allow you to query other databases with out setting up the linked servers.
Yes, it's feasible. You'll need a connection string for each database type (and catalog) in your web.config and you may need to install different drivers on your server (like the ODBC driver).
The only disadvantage I can think of off the top of my head is you won't be able to easily join tables between databases. If you ever have to do that, you'll need to select from the individual database tables and either:
loop through the tables in your code-behind and manually process the data like a join would.
or insert the selected tables into a temporary table on one of the databases and then use that server to do the join .
I am trying to re-deploy my ASP.NET MVC3 application across several different environments and would like to try using SQL Azure. I'd like to use my existing LINQ structure and CreateDatabase to create these databases.
I am wondering how I can use CreateDatabase with SQL Azure since the USE statement doesn't work on the platform.
Please answer with any suggestions or if there might be a better way to do this.
http://msdn.microsoft.com/en-us/library/ee336274.aspx
Important: The CREATE DATABASE
statement must be the only statement
in a Transact-SQL batch. You must be
connected to the master database when
executing the CREATE DATABASE
statement.
You'll have to find a way to fit in this premise. Maybe it's not possible.
Have you actually tried executing this?
I've deployed nHibernate apps to SQL Azure - these apps call CREATE DATABASE somewhere inside the nHibernate layer and they work OK.
Best advice I can give is to try it - then come back with any specific errors you see. There may be some changes to make, but I think these should be small.
I am in the early stages of planning a conversion of a large classic ASP database application to ASP.Net and I'm having trouble picking out which data access method to use. I have played around with Linq To SQL, Dynamic Data, strongly typed datasets, Enterprise Library (Data Access Application Blocks), and a tiny bit with Entity Framework, but none of them have jumped out to me as "the one". There are just too many choices - my head is swimming, help me choose!
Perhaps it would help to give some background on the application that I am converting along with the priorities...
The back end is Microsoft SQL Server (2005 or later) and we are committed to that, so I don't need to worry about ever supporting a different database platform.
The database is very mature and contains a great deal of the business logic. It is highly normalized and makes extensive use of stored procedures, triggers, and views. I would rather not reinvent two wheels at the same time, so I'd like to make as few changes to the database as possible. So, I need to choose a data access method that is flexible enough to let me work around any quirks in the database.
The application has many data entry forms and extensive searching and reporting capabilities (reports are another beast which I will tackle later).
The application needs to be flexible enough to deal with minor changes to the database structure. The application (and database) may be installed at different sites where minor custom modifications are made to the database. Ideally the application could identify the database extensions and react appropriately. In other words, if I need to store an O/R mapping in the application, I need to be able to swap that out (or refresh it easily) when installing the application and database at a new site.
Rapid application development is critical. Since the database is already done and the user interface is going to closely match the existing application, I'm hoping to find something where we can crank this out fairly quickly. I am willing to sacrifice not using the absolute latest and greatest technology if it will save time in development. In other words, if there is a steep learning curve to using something like Entity Framework, I'm fine with going something like strongly typed Datasets and a custom DAL if it will speed up the process.
I am a total newbie to ASP.Net but am intimately familiar with Classic ASP, T-SQL and the old ADO (e.g. disconnected recordsets). If any of the data access methods is better suited for someone coming from my background, I might lean in that direction.
Thanks for any advice that you can offer!
Look at all three articles in this series:
High Performance Data Access Layer Architecture Part 1
Great advice.
You may want to look at decoupling the database layer from the asp layer so that you can not only give more flexbility in making the decision, but when you have to make changes to a customer's database you can just swap in a new dll without changing anything else.
By using dependency injection you can use xml to tell the framework which concrete class to use for an interface.
The advantage to doing this is that you can then go with one database approach, and if you later decide to change to another, then you can just change the dll and go on without making any changes to other layers.
Since you are more familiar with it why not just go directly to the database at the moment by making your own connections? Then you can move the rest of your code and along the way you can decide which of the myriad of technologies to use.
For a new application I am working on I am starting with LINQ to SQL for it, mainly because development will be quicker, but, later, if I decide that won't meet my needs I will just swap it out.
nHibernate might be a good fit. You can store the mapping in external configuration files which would solve your needs. Another option might be using ActiveRecord, which is based upon nHibernate.
nHibernate has a neat feature which you might find helpful. It's called a Dynamic property which is basically a name value pair collection populated by pulling the column names from the mapping file. So when you add a column at your client site, you update the mapping file and you'd be able to access the data through a collection on the object.