we are creating a WinForms .NET4 app with MS SQL Server and we are deciding between two scenarios:
1) WinForms application directly connects to the MS SQL Server.
2) Use 3-layer architecture and insert a WebServices in between.
Questions:
1) Is it a good practice to open SQL connection publicly to the "world"?
2) Which scenario would you recommend. App is data oriented, quite simple and not planning any other client, only the WinForms one.
Thanks in advance.
James
Definitely go with the option having a web services layer. This allows you:
to continue using your domain model (POCO and serialization).
to avoid opening your SQL Server to the internet.
to apply advanced business logic in your web services.
to remove SQL logic from your client application; all the data access belongs on the app tier.
to apply security rules/constraints as you need. Block a customer/user or IP address for various reasons.
When you say "quite simple and not planning any other client", i would take that with a grain of salt, apps always grow and morph as people realise what they can do and what else they can include. You need to rephrase that as "it is initially going to be a small simple app".
WebServices may be overkill for you at this point in time, but if you follow a nice n-tier architecture they will be very simple to add at a later date, with minimal refactoring.
As for exposing SQL to the world - no this is NOT a good practice. You can secure it very well, and ensure the logins that are used by the app (or users if they have their own logins) have minimal rights - just enough to run the stored procedures or execute the CRUD statements on the tables they need access to. But if you mess up the security while it is exposed to the world then kiss your SQL Server and its data goodbye. This is a complex subject in itself, so you are better to post individual questions when you have them.
Related
I have a WCF web service that currently is recording a record to SQL Server 2005 roughly every second throughout they day. Our business reporting team runs SELECT queries against this database in live.
I want to rethink this solution, so that the business reports are not querying our table directly. This is to prevent locking or other performance hits to my WCF web service.
So I am thinking about using another database to hold the reporting data, which will be a transformed version of the source record.
Can anyone point me towards the Microsoft technologies that will allow the WCF service to maintain 100% availability, and the maximum throughput of records possible - so no performance hits.
Without having tried this myself, I would recommend you to take a look at Snapshot Isolation. From what I have read this sounds like what you might need.
we're going to have a database, and a client application that is going to be installed on several machines in a local network, and they must be able to access the DB.
Some of them must be able to edit and modify the DB, and some of them are going to just read them. each of these two groups are separated to several groups too, based on who must be able to access to which table/field.
To create this application, we were gave an advice to deploy a web service to role as a proxy between clients and the DB, in order to secure the DB.
But we're not transferring any sensitive data (such as credit card numbers or...) and we're only afraid of not an unauthorized person be able to modify the DB.
Isn't just using the integrated security option in the app.config sufficient?
Do we really need to hide and secure the connection string?
It could be overkill, but it might not be. Deciding to go to a Service-Oriented Architecture could be based on several factors, among which:
How long are you expecting to maintain this application?
How many client deployments are you expecting?
Do you expect your database to change often?
What are your SLA requirements?
Do you expect the database to eventually be used for other applications?
etc...
The long and short of it is, if you want to be able to change things in the middle tier or database, and you don't want to have to upgrade every client when you do so, adding a Service layer might be the way to go. You also have the advantage of providing a rich API for other client developers (internal or external) while controlling business rules and security in one, centralized location.
SOA definitely adds to the complexity of the project, but in many cases, it can save you a lot of headaches in the future.
For further reading, look at http://en.wikipedia.org/wiki/Service-oriented_architecture, http://www.soapatterns.org/, or Google.
Sounds way overboard to me. If the application is only going to be used internally, and Windows authentication is an option, certainly use it. Building a web service is only going to slow down development and add an unnecessary layer of complexity. The read/write users could be members of a Windows group that has read/write access to the database, and the read-only users could be members of a Windows group that only has read access to the database. Then, if the user is able to gain direct access to the database (without using your front-end) they would only be able to either read or read/write based on their Windows rights.
Greetings!
I have recently built out a template for one of my clients that includes a lot of new features, not the least of which is EF/WCF RIA.
Deployment time is greatly reduced when I can connect via EF directly to a table. No more CRUD SPROCs for all 50 tables. I've read that EF, by default, doesn't allow for standard SQL Injections, but I am wondering if anyone can provide me with a comprehensive security overview, or at least enough data where I can sit down with the senior DBA/Security guy here, and convince him that writing all of the CRUD SPROC's aren't necessary.
I've read MSDN Security Considerations (Entity Framework), Security for WCF RIA Services, and a slew of other articles, but I thought I'd give SO a try and ask for some real world implementations & hard evidence in terms of security & EF.
Your thoughts are greatly apprecaited
The senior DBA/Security guy here had a lot of questions about how
Your client program never access SQL directly, instead they are calling RIA Service and RIA Service is inside your ASP.NET, which is completely under your control.
You can intercept your ObjectContext by overriding methods like SaveChanges and you can limit your IQueryable in your RIA Services Template classes.
C# or VB.NET code is very easy to read and understand instead of stored procedures.
Maintenance of stored procedure is sure a pain.
RIA Service provides you method templates where you can intercept logic and manipulate and monitor actions taken against database.
The one and the only difference is, your logic of monitoring and manipulation for CRUD executes inside ASP.NET Application Pool in case of WCF RIA Services and in case of Stored Procedure, it executes within your Database server.
In both the cases, your client has no direct access.
EF already validates your data before storing in DB against the model you have created.
Future edition of SQL Server is coming with inbuilt modelling tools which will anyway deprecate stored procedures for CRUD in some way.
I had to deal with this as well. I'm not sure if your situation is the same in the sense you can still use EF with proc function exports. I can't say I did any better but I did educate the DBA person on the WCF RIA security boundaries. Meaning if someone can get authenticated they'll still be able to call the service methods that call the procs. So I guess in my opinion there isn't a huge difference to exposing the entities you need vs exposing service methods that call procs. I was able to get the person to loosen up their restrictions when I showed them how easy it was to do CRUD operations with Linq to entities, which meant less work for them.
I have a Windows Application in C#. This application interacts with a remote mySQL database. Should I create a PHP web service to do these (insert/add/delete/update) or use mySQL connector for c#? I'm not sure which way is better.
Thanks!
Wether the MySQL server is in the same network (phisically) or not. From my point of view the according solution would be to create a dedicated Web-Service that provides you the CRUD functionality for your application.
This, because it gives you some Separation of Concerns (SoC) as you can separate business logic tier from the data access tier.
See also: Single Responsibility Principle | "In object-oriented programming, the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility."
Every part of your application serves a specific purpose which makes it easier to maintain over a big timespan.
Now this sounds pretty nice and cool, but do we really need to abstract everything away?
As with everything else, it depends.
Here is a little Use-Case:
The Database needs to be modified: Tables keys are removed, new tables are added old tables are removed.
What will you, as developer, need to do in order to keep your application working?
Using MySQLConnector:
Start "hacking" inside your source code and making sure all queries run as expected. And if something goes wrong during that process, it will be a pain to fix it because it's all kind of nested within the application logic.
Using a dedicated Web-Service:
Just make sure your methods are updated to match the new database design | No need to change anything on the application-side [except method arguments in some cases].
Cheers
Why use PHP web-service when the application is in c# ? just use the MySql connector for C#.
Secondly web-service performance will be slow compared to MySql connector for C#.
I will be building an in-house, Occasionally Connected App (OCA). What technologies would you suggest I employ.
Here are my parameters:
.NET Shop(3.5sp1)
C# for code behind (winform,wpf,silverlight)
SQL Server Backend (2005 or possibly 2008 pending approval)
Solo Developer
Solo SQL Administrator
Low Tech end users
Low bandwidth to 5 Branch offices
This is a LOB app but not a POS.
Majority of users have laptops that they take to Member's Home
The Data for this App is stored in 5 separate Databases, though in one SQL instance.
I am looking for specific recommendations on which path to choose. Merge Replication or Sync Framework database synchronization providers? SQL Express or SQL CE at the Subscriber? Can I use LINQ to SQL for the DAL?
Is a Silverlight 'Offline/Out of Browser App' Example Here, feasible?
This is my first LARGE business application so any experienced comments are welcome.
As requested here is some additional info on the type of Data. My users are Nurses and Social Workers who go to Member's homes and create "Plans" or "Health Assessment Reviews" for them. These are things like a Medication List or a List of there current "Providers". Steps to achieve members' goals or a list of there current/past Diagnosis's. Things like that.
Also the typical Members Name, Address, Phone Number, etc. Mostly this is a Data Storage and Retrieval app that facilitates reporting. Very little "processing" takes place and Nurses and Social Workers work in teams that are assigned members so I usually have very little crossover or potential data conflicts. Nurses and SW's also are responsible for different area's of the MCP(Member Centered Plan)
Additional question; Is Sync Framework really only a viable option if I can use SQL 2008? Seems that way due to the Change Tracking etc....thoughts?
Once you solve the problem of change detection and data movement, everything else is trivial. In other words technologies like WPF, Silverlight, Forms and even WCF are orthogonal to your main problem and your choice should be based on your personal preferences and experience. The real hard nut to crack is working disconnected and synchronizing changes. Which leaves two out-of-the-box avenues: Synch Framework or Replication.
I would say, for your scenario, definetely Synch Framework. Merge replication, like all forms of replication, is designed for systems that are connected continously with intermitent disconnects. And most critically replication can work only over static names. Laptops connecting from various hot-spots and ISPs have a nasty habit of changing FQ names with each connection. Replication can overcome this only if a VPN of sort is used and VPN is usually a major support issue. Replication is just not designed for the high mobility of OCA systems.
Synch Framework will pretty much force you to SQL 2008 back end because of the need to Change Data Capture or Change Tracking, both being SQL 2008 only features.
You will still have plenty of hard problems to solve ahead (authentication, versioning and upgrade, data conflict resolution policies, securing data on the client for accidental media loss etc etc)
Personally, I would say:
.NET 3.5
WCF Data Services (for communication between the client app and your data)
SQL Server 2k5/2k8 (whichever you can use)
Silverlight w/ Out of Browser Functionality
VistaDB (to store data locally on the client until you can push to the server)
use unique-identifier for key if you are creating stuff while offline and not connected and when you do connect, updating the database.
this is going to be way easier than using auto-increment key
Having worked on an occasionally connected application, I'd encourage you to look in to SQL Server CE for the client machines, with Sync Services to handle the connections. Here is a good tutorial.
You could create this stuff from the ground up, it seems.
However, this seems an awful lot like a CRM application, and it wouldn't surprise me if you could find an enterprise software package to do this without starting from scratch and instead modify one of the configurations to meet your business rules.
In a previous life, I was a configuration developer for this thing called Siebel that might be close to what your'e looking for. They even have a built-in synchronization tool called Siebel Remote.
It might be a cheaper route to go than rolling your own from scratch.
I wrote an order taking program for wine sales reps. Here is the video. The client software is installed using click-once. That also installs SQL Server Express and loads the database. I used the Microsoft Sync Framework to sync the local database with the one on the server (see the last section of the video.)
With powerful clients now I don't see any reason to not use SQL Server Express, it is free with a limit of 4GB.
SQL CE had too many limitations - no stored procs being a major one.
You will need to use GUIDs everywhere as the primary key - see the new NewSequentialID().
I love click-once, it is a big time saver.
I'm looking forward to Silverlight, but just haven't had time to look into it. Not sure if I would have done it with Silverlight if doing it now or not.
Having said all this, this is not a project for anyone inexperienced. So I would also get some very experienced help.