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.
Related
Is it possible to mock, or create a facade, to replace a SQL Server database in-place, currently being used directly by a website via ADO.net, with a service (ideally WCF or other .NET technology)?
Example:
Consider an ASP.NET website with a lot of features which use SQL Server 2008 over ADO.NET. The SQL transactions involve many stored stored procedures, though there are some direct T-SQL transactions. It would be powerful to be able to replace the (singular) SQL server with a more scalable implementation, without having to re-implement the website features.
This could be a shim for ADO.NET, or an ODBC driver to a custom service framework, or something else. The "right" answer may seem to be "reimplement the website to use a more abstracted data interface", but let's consider that the website code is immutable (though configuration could be altered).
Maybe simply provide an data access layer that specifies well designed interfaces. Your website will only ever have a handle on an interface, and you can use dependency injection/IoC to provide your concrete implementation of your interface on an as needs basis.
It's not an "existing technology" as such, but probably just a prudent way forward in your design I'd suggest.
I have the following scenario:
Server
SQL Server 2008
Core (Entity Framework and business logic)
WCF Service
MVC Web application (for backend management)
Client
Local Database - a simplified model of the main database
WPF Client
Requirements
The client has to work fully offline, and persist data
Changed data should be pulled from the server over WCF service
Client should not change the data, but call a a WCF method (if not available queue the call)
Possible Solutions
Microsoft Sync Framework - I think its an overkill, because I mainly need one way synching, and also the data structure is not the same.
Datasets serialization over WCF, yes, because Datasets support merging and offline scenarios, but isn't It out of date?
Entity Framework? I tried to build a prototype, but EF doesn't seem to support my needs very well (I need to search for an entity, and change it if modified, or add it if not existant)
Question
What, do you think, is the most appropriate approach?
Is SQL Server Compact a good local db?
I am very interested in your thoughts. Thank you!
The Microsoft Sync Framework is in my opinion not appropriate because you have differing schemas. I can also imagine that you have some business rules about what data is allowed to change and how it should be synced.
The choice between DataSets and Entity Framework depends on your needs. An Object-Relation-Mapper comes in to view when you are really using an object model.
If your domain is complex enough and you have the knowledge using a full fledged Domain Model is definitely a nice solution that can scale really well and handle complex projects.
If your project is somewhat simpler and you don't want to build a Domain Model you can choose for DataSets.
Personally, I think that learning the ins and outs of Domain Modeling and the Entity Framework as an ORM is a nice choice for projects. When you have enough experience using these technologies, you will even favor them on small projects.
About the problems you where having with your EF prototype.
Because the data schema of the client and the server is different I would use custom Data Transfer Objects for moving data between the two. This way, you decouple the object models and they can change independent of each other.
The client knows everything there is to know about the data changes. Because it has a local representation of the server data it knows if data is added, changed or deleted. Why don't you add this knowledge to your server call? If you use a field in your DTO that states if the object is Added, Modified or Deleted, the server won't have to detect this.
In my first c# project, I need to connect to a database server for multiple read only queries. Would anyone share experiences on how to organize the queries into the project? currently I just hardcoded query strings in the c# source files whenever needed. but it is hard to maintain and once something changes on the database server side I am in trouble. Or should I put all query strings in the .config file using appsettings? Are there better ways? I do not have rights to save stored procedures on the server. thanks.
There are different answers with varying levels of sophistication based on your needs. Except in the very smallest of projects, I create two class library projects for database access: one that contains the data model and queries and another test project that exercises the first project's queries. In simple solutions, you use this library in an ASP.NET or other project.
You should strongly consider learning an ORM like NHibernate or VS 2008/.NET 3.5's Linq-To-SQL or Entity Framework. Minimally, you MUST remember to use parameterized queries if you have a web-facing app.
In more sophisticated solutions you will completely encapsulate the database into it's own service, or tier. In my experience I had a data access tier that ran in it's own Windows Communication Foundation service, as a Windows Service, and it was the only service that could talk directly to the database or knew the database's data model. It would do all the interaction with the database, and then transform the data into different data models that are read by the other tiers. I typically create a project called "Contracts" that contains all the interfaces and data models that are communicated from the data tier to the rest of the system. The reason you do this is so that you avoid the pain you have mentioned: you can update the underlying database, ORM layer, and "common data models" and then not change the other tiers at all.
If this is your first project, try to keep thinks simple. If you add too much variables probably you'll end thinking more in technology than in solutions.
That said, if your queries don't expect to change it's parameters, you can use stored procedures. This approach also will help boost your queries as the execution plan will be kept in the database.
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.
I'm writing a .NET application and the thought of implementing a data layer from scratch is icky to me. (By data layer I'm referring to the code that talks to the database, not the layer which abstracts the database access into domain objects [sometimes called the data access layer and used interchangeably with data layer].)
I'd like to find an existing generic data layer implementation which provides standard crud functionality, error handling, connection management - the works. I'll be talking to SQL Server only.
It doesn't matter to me if the library is in C# or VB.NET and I don't care if it's LINQ or ADO.NET. As long as it works.
** I want to emphasize that I'm not looking for data access technologies or mechanisms (e.g. LINQ, ORM tools, etc.) but rather existing libraries.)
If you are talking to only SQL Server the Linq to SQL is your best option. It is pretty easy to get up and running. You will get both the Data Layer and the Abstraction. All you have to do is provide a connection string to Linq to SQL and it will handle the rest.
If you are going to connect to other database than SQL you would want to with NHibernate.
NHibernate takes a little more work than Linq to SQL to get up and running. MS provided in Visual Studio a nice tool that can get you reading from a SQL database pretty quick.
Honestly as much of a fan as I've always been with NHibernate. With the latest release of Enterprise Library 5 Data Access Block that they added in the dynamic mapping support natively. I would have to strongly consider not using NHibernate on a project and instead use a forward database generation tool from my domain objects to create my database (perhaps even use NHibernate solely for the scheme export) or something like CodeSmith and use EntLib.
You can use easyobjects has a very small learning curve, and is very extensible.
From their web:
EasyObjects.NET is a powerful data-access architecture for the .NET Framework. When used in combination with code generation, you can create, from scratch, a complete data layer for your application in minutes.
I'd like to find an existing generic data layer implementation which provides standard crud functionality, error handling, connection management - the works. I'll be talking to SQL Server only.
Might want to check out Subsonic. Though I personally find it quite limited, it's certainly not an ORM, but a "query tool." It will make CRUD operations easy and straightforward, and it generates partial POCO classes for every table in your database, rather than trying to map from a database to a domain layer.
Microsoft's Entity Framework might be what you are looking for to releave you from writing "the code that talks to the database".
The best things are that it already ships with Visual Studio and - depending on your requirements - you can use most functionality out-of-the box or manually adjust it to your custom business logic via T4 templates.
You can use it for forward and reverse engeneering and being a microsoft technology it integrates well with other MS products like SQL server.
I started using it 3 months ago in my current project at work which is composed of several windows and WCF services to convert third party data into our own database scheme. From the experiences we made with it, we'll be using the EF in future project a lot more.
What would you expect this framework to do with your exceptions? If it can't connect to your database, what should it do - crash the application, show an error message (winforms or WPF or ASP)... the questions are endless.
An ORM such as those suggested elsewhere in these answers is likely to be the closest you're going to get. Expecting a third party framework to provide all your exception handling isn't realistic - how would a third party know how your application is supposed to behave?
The direct answer to your question asking for "an existing generic data layer implementation which provides standard crud functionality, error handling, connection management - the works" is simple: use ADO.NET. The answers everyone else have provided actually go beyond that functionality, but your responses suggest that you think that there's something even further beyond - something that implements your data layer for you. My suggestion is that what you're looking for probably doesn't exist.