I'm currently working on an Intranet application project, using ASP.NET MVC 3.
One of the primary requirements is that all data created with the application must be available in the clients' ERP software as well; they work with MS Dynamics NAV. Accessing the data is not really a problem, as NAV uses SQL-Server as its database.
In fact I already have a working prototype, that uses Entity Framework for data access. The main issue here is that my company also develops quite a lot of custom functionality within the ERP, and thus some of the database tables I have to read from and write to often change. This would not really be a problem in a usual situation, but here, each and every field in the database is marked as not null, a very annoying feature of Dynamics NAV. That means that every field added to a table breaks my code, as Entity Framework tries to insert null when it doesn't know of a field.
Can any of you think of a solution that would not require regenerating the model after each change in the tables ?
Edit : Unfortunately our client still uses version 4.0 of Nav, so webservices are not an option.. I have already developed another application for them (part of a Warehouse management system which runs on mobile terminals), accessing SQL Server directly, but it was not quite the same scale.
If your requirement is to integrate with ERP like Dynamics NAV you should pass all data access through its application server. I think Dynamics NAV expose web services for communication with application server. Accessing its tables directly is way to disaster especially due to transactions and possible deadlocks. EF will make this even worse because you will not be able to tweak queries.
Application integration through database requires full control over SQL generated by all accessing applications.
The answer to your main question is no. The point of database first development is to regenerate your model after each database modification - especially if each database modification is breaking change (another reason why integration through database is not a good choice for you).
Related
I am tasked with creating a reporting application working off a internal database.
The database is populated by some other tools, and the aim of the application is basically to read from the DB, and display some charts.
To that end, the application will only ever connect with a read-only account.
I have been reading about ORM, especially Entity Framework, but is seems to be very focused of making DB structure, and DB updating easier.
Since the only purpose of the app is reading from the DB, will I gain anything from using an ORM such as Entity Framework or Linq2SQL, or should I stick with good-ol' SqlCommands?
If you need some kind of dashboard to display aggregated data from a SQL Server database I would recommend Reporting Services. You would need a SQL Server license on the machine that serves the site.
You can of course create a dashboard from scratch using Entity Framework, but hey, why reinvent the wheel?
Ok, let me explain the environment we are facing here:
We have an ASP.NET MVC 4 app that uses a SQL Server database.
This app isolates data in "projects", so when any user connects to it only can work on the data of one of this projects.
Sometimes... a group of users have to travel to remote regions for some days to retrieve data for a single project, and quite often they won't be able to have an internet connection (even mobile or satellite solutions are often out of reach).
While the displaced team works on a project, people at the office still can work on the rest of the projects (but no on the one that is abroad).
So... we are pondering the possibility of using a laptop to act as a "mobile server", where users can download the data from a specific project before travelling. While abroad, they can work against this "mobile server", update any data on their project and, when they come back, they could upload their updated data to the main server.
Our idea is to create stored procedures on both servers (main and mobile) that executes different queries to update data from a project between them, passing the project identifier as a parameter. Probably using Linked servers to allow main and mobile to see themselves during update operations.
Our questions here are:
Is this a good aproach?
Is there any other better approach that we're not seeing?
Are there any risks we should pay attention to in this or other approachs?
I've never used Bidirectional transaction replication so if that works for you, problem solved. I do have quite a bit of experience with data migration, including merging large data sets into software driven systems. And from that experience, replication has hurt us more than it has helped us (from a migration/merge view).
The biggest challenge in my opinion is going to be conflict resolution. I know you say that all of the data is in project specific databases, but there is no shared data at all? What about multiple remote users updating the same data? In that case you're going to need a little more than just replication.
Instead of maintaining two databases at all times (one for mobile, one as the regular in-house db), why not a system where a job is called to your main system indicating that a project needs to be prepared for "offline mode" (the job could be stored procedures or SSIS packages or straight T-SQL). Whatever the technology used, this job would copy all of the requested project data to a new database on the remote server/laptop and mark it somehow in the main database as read-only to prevent users in the office from updating that data.
Once the data is in offline mode on the remote server, the users can update and use the data as much as they want from that remote server. Then when the users get an internet connection or they are back in the office they can kick off another job that syncs the data to the main server, removes offline mode, and deletes/archives the remote database. Almost like a temporary project database.
Seriously, it sounds like a fun project.
Technologies to look at:
SSIS (Sql Server Integration Services) - In my experience, this is extremely fast at moving data and allows you the ability to add logic to handle conflict resolution, error logic, etc. It's free (with certain Sql Server editions) and the community is huge so supporting it should be easy. SSIS is not as dynamic as some of the specialized solutions out there.
A data migration suite like Pervasive's Data Integrator - I loved this but it's expensive. You could right an entire solution in this product that could handle the processing of your data bidirectionally and like SSIS it allows for complex programming logic.
T-SQL - With a linked server you could just write straight queries (using stored procedures if you wanted). The problem here is security on the linked server. We don't use them because of this issue. Linked Servers: Good or Bad?
Start using some of Microsoft's built in change detection technologies right off the bat. It's harder to implement when you're already using the system. Change Data Capture (CDC) will give you a full history of the records updated while Change Tracking will give you a light-weight summary of your changes. Using either technology will make syncing the data many times easier.
Change Tracking: http://msdn.microsoft.com/en-us/library/bb933874.aspx
Change Data Capture: http://msdn.microsoft.com/en-us/library/cc645937.aspx
SSIS: http://msdn.microsoft.com/en-us/library/ms169917.aspx
SQL Server Agent Jobs: http://msdn.microsoft.com/en-us/library/ms189237.aspx
Presently I have a Windows Forms application that obtains data from a SQL Server database on a separate server in our LAN. Basically we want to re-use as much as possible our source code that interacts with the SQL Server database and change the forms portion to a thin client silverlight solution. The problem is that our Windows Forms application is a fat client application; however, our company recently added employees working several thousand miles away, so they have a long delay in working with our application as it retrieves data from the database server which is a long ways away from the employee's client forms application.
The ideal solution for me would allow the developer to display data based on various database tables or views dynamically at runtime say based on what treeview item a user clicks and not having to hard code the database schema at design time. This is the way our windows forms application presently works.
One aspect of silverlight I am wrestling with right now is that if you want to access data from a SQL Server database on the web server side you have to use web services or WCF RIA, which of course involves creating a design time EDMX file or generating LINQ to SQL classes. The problem is that our database schema changes quite frequently, so that means I would have to keep manually re-updating the web services along with the EDMX and/or LINQ to SQL. What I would really like to do would be to just connect to the SQL Server database using ADO.NET to populate the various silverlight datagrids without having to deal with web services. Please note that I am pretty new to Silverlight, so perhaps I am missing something obvious.
Here is one of the many links I have checked as I've been working on this solution; however, this just migrates a Windows Forms application that already has a web service to a silverlight application that has a similar web service, so it doesn't seem to apply to my situation:
http://www.silverlight.net/learn/advanced-techniques/moving-from-windows-forms/migrating-a-windows-forms-application-to-silverlight
Here is another website that I have been looking at closely; however, the database that I am working with is so huge and has such a large schema that whenever I attempt to open or work with the Data->Show Data Sources or Data->Add Data Source window in Visual Studio it takes about an hour of the CPU running at full throttle before it displays the values in visual studio. Of course this makes Visual Studio almost unusable if this hour long wait happens every time I try to make a change in the silverlight XAML designer:
http://msdn.microsoft.com/en-us/gg315272
Also, the website example above is not an acceptable solution because we want the web server and the database server to be two separate machines, so we would not be able to put the database into the App_Data folder in the silverlight solution.
If anyone has any suggestions or guidance in terms of migrating this application, they would be most appreciated. TIA.
Roger
Basically I found out that since I'm used to writing desktop applications that communicate directly with a database (such as SQL Server), I was surprised to find that there is no object in Silverlight to enable you to do (SqlConnection, OdbcConnection, etc.). This is because Silverlight is a client platform, designed to be run from within a browser anywhere in the world, and so it does not make sense for it to be able to access databases directly because databases are generally hidden behind a firewall. The purpose of a service is to provide an interface for exposing data publicly from the server, acting as a conduit between the data in the database and external applications. (source: "Pro Business Applications with Silverlight 5" by Chris Anderson)
Please note that I also had made a mistake when I created a DomainService and assigned to it all the tables, queries, and stored procedures in the entire database, when in fact one needs to create a separate domain service for each individual table or query. This explains why I had the problem before where I had to wait about an hour for the Data Sources window to populate.
My company is planning to turn an older Winforms application into a WPF/Silverlight Client/Server app.
The idea of having a small server app is to have a list of the accessible data bases combined with the user type that may access each of the databases, instead of having to manage databases in each client's admin control. Additionally, it would be great if the SQL request would be handled by the server which would then return the result.
The app is supposed to work on a arbitrary set of databases which will be "registered" with the server and users get a list of databases according to their authentication rights. They can then do practically everything on those databases what one can imagine. The system should be able to handle up to 2 million rows.
The databases are very different, there can be many of them, they can be MS Access, Oracle, SQL Server etc., so no way for me to specify them all before. On top of that, communication with a SQLite cache is needed.
I already have everything I need for the SQL queries from the Winforms app.
I was thinking:
1) A simple WCF server specifying in a config file the available databases per user type.
2) Interface that specifies all necessary SQL queries that can be made to the server.
3) Client...
The idea is:
a client-server application, where the client uses WCF services to execute SQL queries (INSERT, UPDATE, SELECT, etc.) on tables by invoking services methods.
The service should ideally be consumable for both the WPF and the Silverlight app.
Is that the way to go? Which exisiting technologies might I want to make use of regarding formats, communication, services etc.
If that is problematic, I would consider going back to a desktop app, but then how to ease the user type/database access problem for each client?
I would stick with ADO.NET and start with the DbProviderFactory class. This will let you determine the proper database access based on information supplied by the provider using the Factory Design Pattern. So instead of having to create a specialized objects for each database type and database, you can abstract that logic with the DbProviderFactory.
Here's a link that shows some examples: http://msdn.microsoft.com/en-us/library/wda6c36e(v=VS.100).aspx
I'm going to develop a Web Application with two essential requirements:
Total independence of DBMS. The application should work with different DBMS like Oracle, SQL Server and MySQL. That is, Client 1 use this application with SQL Server, but he wants to migrate to an MySQL Database. The application should be able to work with this new DBMS without needing to make changes to the application code. The only change I want to do is to change the connection string.
Scalability. ie, we will have a clustered SQL Server installation.
I know that Data Access Block is able to handle different DBMS and I assume it won`t be an issue to meet the scalability requirement, but I don't know if this is the case with Entity Framework.
Choose Entity Framework, for a couple of reasons.
First, EF is where Microsoft is putting all its data access emphasis for the foreseeable future. Entlib's data block is primarily there to support folks already using it.
Second, Entlib will give you a regular API, but it doesn't insulate you from the differences in SQL statements. Oracle in particular does stuff with cursors no other database does (or needs to); EF at least attempts to give you a uniform API.
As far as scalability, that's all about the design of your database and application, no data access tool will give you that.