My team is considering using an up to date version of Entity Framework with a WinForm or WPF application which will be downloaded by users and installed on their machines.
This will connnect through WCF to our database, and the app will use LINQ queries through EF to interact with the database.
Is this secure? Can the application be reverse engineered, and a competitor see our database structure and business rules?
Is this architecture acceptable? Or if the risk is high, should the structure be abstracted behind an interface?
I imagine it depends a bit on how your WCF service is going to work. Webservice or Windows Service? Encryption? If you are not encrypting and you are serializing your returned objects in XML, it is possible someone could snoop that XML stream, and get an understanding of the structure of the entity (Pretty sure mapping information or Storage Layer information is not included in the serialized entity).
As far as Entity Framework goes, assuming an attacker cannot get to the edmx or the resulting EDM constituent files, and they can't get access to the database directly, you should be good. Entity Framework EDMs compile pretty similarly to other assemblies. So long as you secure the transport from service to client, you should be good.
Related
We have a mobile application made in VB.NET for Windows CE/Mobile smart devices for shipping/reception operations in a warehouse. This application connects to a SQL Server and extensively uses stored procedures. Since Windows Mobile devices are discontinued and replaced by Android devices, we have to convert our solution to Android, using Visual Studio's Xamarin and C#.
I'm a newbie at Android programming. Is there a way we can connect directly to a SQL Server instance and call a stored procedure from Android? I made some searches and people says it's better to call web services as an intermediary between Android and SQL Server. Is it the best practice?
Thanks for your insight and help
Upgrading Legacy applications can be incredibly complicated depending on the technology and frameworks used.
The first thing I would suggest taking a look at is the Architecture documentation Microsoft produced for Xamarin and Cross-platform frameworks which you can see here
Typical Application Layers
Data Layer – Non-volatile data persistence, likely to be an SQLite database but could be implemented with XML files or any other suitable
mechanism.
Data Access Layer – Wrapper around the Data Layer that provides Create, Read, Update, Delete (CRUD) access to the data without
exposing implementation details to the caller. For example, the DAL
may contain SQL statements to query or update the data but the
referencing code would not need to know this.
Business Layer – (sometimes called the Business Logic Layer or BLL) contains business entity definitions (the Model) and business logic.
Candidate for Business Façade pattern.
Service Access Layer – Used to access services in the cloud: from complex web services (REST, JSON, WCF) to simple retrieval of data and
images from remote servers. Encapsulates the networking behavior and
provides a simple API to be consumed by the Application and UI layers.
Application Layer – Code that’s typically platform specific (not generally shared across platforms) or code that is specific to the
application (not generally reusable). A good test of whether to place
code in the Application Layer versus the UI Layer is (a) to determine
whether the class has any actual display controls or (b) whether it
could be shared between multiple screens or devices (eg. iPhone and
iPad).
User Interface (UI) Layer – The user-facing layer, contains screens, widgets and the controllers that manage them.
Now you could just simply use the System.Data.SqlClient assembly and fire off stored procedure runs against your database. However a more common approach would to create an REST Api that sits in-between your client and your back-end services.
You can download a handy E-book created by the Devs over at microsoft that will show you some common enterprise patterns to use for Cross-platform technologies like Xamarin which can be found here
Here's one such example of the kind of patterns those links refer to.
You can also find an overview of various web services that you can use at this link
The options it gives you an overview of are:
ASMX
WCF
REST
So plenty of choice, but depends on your current approach.
I am building a desktop application that will be used on local network, with SQL Server as database.
This application would have around 50 users top at the same time. In what particular scenario would I need to use WCF service? Is it recommended to create a WCF service on the server computer where database would reside, so we connect to this server through WCF service, instead of connecting to the database directly? What is the recommended way to connect to SQL Server data and why?
Edit: Let me explain in more detail. I have used WCF Ria services before, so I know how they work. Lets assume that WCF services works in same way. The question was directed toward why would we use WCF instead of directly connecting to database? I didnt want to specify my current application requirement, since I would get a specific answer for specific requirement. My goal was to understand in general why and when would you yse one instead of another. And I have received satisfying answers so far.
It appears to me that general consensus is to use WCF only if there would be a demand of another type of application, which would use web access to get data from service. Also, if I understood correctly, from security point of view, there is no difference between the two.
There would be a statistical app in the future that uses web to provide read-only statistics to user, and naturally some service will be required for this task (application has no specific client in mind, it will be offered to lots of clients). Since I need some demo application to be done very rapidly for particular clients, then I am thinking to neglect the service part, and make a proper layering (WPF->VM->Model->EF, so later I would just insert service between the model and EF. I guess it should not take too much time to make WPF app running with inserted layer. I am also postponing the service because of next reason: since HTML5 is (going to be) main technology for web, and there is a possibility that SL will be abandoned as technology (which I have been using), the logical decision would be to choose HTML5 over SL. But since I am totally unfamiliar with HTML5 and its requirements, I am not sure if WCF service is the best choice for it, and this is also one of the reasons to postpone the decision of choosing the service type (along with requirement to make the desktop demo app as fast as possible).
I think a better way to consider the question is whether you should abstract your database and data access layer from the application using a service interface. You could use WCF and SOAP or you could use a REST based HTTP service, the choice of technology is secondary to whether the current or future requirements of your application indicate that an additional layer of abstraction is warrented.
Reasons you might consider using a service interface instead of directly connecting to the SQL database include but are not limited to:
Ease of supporting multiple operating systems/client UIs
Ability to evolve the data/service interface separately from your database schema
Isolate application from changes to database schema or location (you don't have to redeploy change to application, only change internals of the services it is calling)
If data could be used by other systems, you have a standard means of allowing these systems to interface with the data your application is managing
Reduced SQL database connection security concerns (only service identity connects to database, allowing you to use a variety of authentication/authorization strategies on the client side)
The trade off you are looking at is the time/cost/complexity of implementing a service interface versus the flexibility and mantainability benefits you will gain. You should evaluate the needs of your application and your customer before you make a decision on whether to connect directly to your data store using ADO.NET or use a service layer.
You should take a look at the Microsoft Service Layer Guidelines as they cover a lot of the considerations to take into account.
Unless you need to create a reusable service, I can't think of a reason to add a WCF layer, unless you are just looking for a reason to do it. I think you can just go with some sort of ORM like EF or nHibernate and be happy.
The main reason for WCF is security. If the client connects directly to the DB then the client must be given rights on tables. The client can hack into the connection and use TSQL directly. You must expose port 1433 to the network in a single tier application. With WCF there is not direct access from the client to SQL. It is not just more secure in general but you can have more granular security. .NET service code can enforce row level security. A table only has column level security. If this is business on a private network and you don't expect anyone would try and hack into your db then client connecting directly to the SQL server is easier to build. With server side service the other factor is a change to server side code is one spot so you don't have to update 50 devices.
I am doing something I consider to be pretty normal (although I personally haven't had to do it before), and I have assumed there'd be a 'no-brainer' way forward, but Im yet to find it - which is really frustrating.
I will be creating a WPF application, which is a data-oriented business application. My data will come from a remote IIS server (that I control) that has a standard SQL server 2008 database, so Web services/WCF seem to be the way forward. The remote service needs to be secure (reasonably) via a user (of the WPF client) username/password login.
I dont want to use 3rd party ORM products, but I expect the data layer (between the service and the database) to be able to cope with very simple ORM type functionality (I really dont want to hand-craft a data retrieval and persistence layer). Im not worried about concurrency very much as this will be a fairly simple app.
My options seem to be one of the following:
ADO.NET Entity Framework over WCF
Linq2Sql over WCF
WCF Data Services
On further investigation, none of the above seem to be the 'no brainer' Im after
1) ADO.NET entity Framework - Ive had a play with this and getting all sorts of issues serializing objects over WCF. Even when I try to generate POCO entities and use them, Im having to decorate service contracts with custom attributes just to get it to not error all the time, and I seem to have to hand-crank anything more than a flat object graph. It seems to me that EF simply isn't designed to be exposed via a service.
2) Linq2Sql - This doesn't seem much better than EF. I seem to have to hand-crank too much stuff. Ive tried the designer and SQLMetal but nothing seems to 'just work' - it all needs fiddling with.
3) WCF Data Services - this seems like a good option on the face of it, but essentially it seems like I'm just exposing my SQL database tables 'in the raw' over the service layer. Im not an expert in this technology by any means but it seems like a potentially dangerous approach, and on top of that it doesnt seem to support any kind of access security as standard (you have to hack it to require authentication it seems).
As I said, this scenario feels like it should have a no-brainer solution, but Im still scratching my head. Ive done lots of things with .NET technologies, but to be honest this area represents a bit of a hole in my understanding, so I apologize if any of my comments or assumptions are naive.
Of course, it may well be that the 'hacky' long-way-round on EF or Linq2SQL may be all I can do, in which case I can roll up my sleeves, and accept the fact that I haven't missed a more elegant solution.
Any help/advice will be much appreciated.
This is a tad subjective, but i'll offer my opinion.
First of all, forget L2SQL - it's basically obsolete and doesn't have the full POCO support of EF4 (it can be done, but needs XML tinkering, or SQLMetal generation), which means serializaing your entities will be a left-to-right entity cloning nightmare.
I would go with ADO.NET Entity Framework over WCF, Entity Framework 4.0 specifically. You will have a wealth of flexibility in your model (including the ability to apply OO principles such as inheritance).
Use Self-Tracking-Entities. Yes, you have to decorate service contracts - this is by design, and there are many reasons for this.
You could always use DTO's, as opposed to serializing the actual EF entities.
OData is really good as well in it's flexibility and simplicity. But if your only consuming your model via a single client application, a specialized service layer (WCF) is a better approach IMO.
3) WCF Data Services - this seems like
a good option on the face of it, but
essentially it seems like I'm just
exposing my SQL database tables 'in
the raw' over the service layer.
That might be a first impression - but it's fundamentally wrong. What you're exposing over the web is a model - and you have full control over what gets into that model, and how consumers of your WCF Data Services might be able to see and/or even update entities in that model.
That's where Entity Framework comes in and shines (and where Linq-to-SQL miserably fails): you can grab your database (or at least parts of it) into an Entity Data Model, and then modify it. You can tweak your entity names to be totally different from your table names, you can add computed attributes, you can remove certain attributes and much more.
If you're talking about a fairly simple app, that's definitely the way I'd go:
grab your database and turn it into an Entity Data Model using EF
expose that EDM over WCF Data Services and define what can be seen read-only, and what might even be updated over the wire
I'm a little confused here.
I have my POCO classes created with the entity framework modeled from the datbase.
Obviously, I'd like to use these classes in the client too (and any bookkeeping on them would be nice if I'd like to send them back and re-attach)
I looked through the classes generated for the WCF service reference and it seems a bit verbose to be sending over the internet, but it doesn't look like there's anything risky in there security-wise.
And yet, I can't find anything online about doing this. Am I going down a completely awful path?
Help?
EDIT : I suppose they're technically they're not POCO classes if i had them generated by the EntityFramework from the database; just to clear up any possible confusion.
This is a difficult question to answer without knowing more details about your system, but ultimately whether exposing your EF entities in the WCF service contract is the right path or not is influenced by the scope and requirements of the application you are developing.
Perhaps ask yourself the following questions which will hopefully guide your decision:
Is it likely your relational model and object model will need to diverge? This can be driven by a number of factors, but most commonly reporting requirements may enforce a certain design on your database schema (for performance) that you do not want to reflect in your application object model. Using the DB generated EF entities throughout the application layers can bind you to this database design
Are you concerned that changes to your database schema may require your clients to regenerate their service references? Again, using the EF entities throughout your application tiers means any changes implemented in your DB schema (whether of concern to the client or not) may bubble up to the service interface, potentially breaking client compatability with that interface
Is performance a concern? As you mentioned, the generated classes are verbose. You are likely to be transporting unnecessary baggage across the wire, which could be optimized.
Are you concerned about exposing the implementation details of your database schema and persistence mechanism on the wire and to your clients? Given you have generated the model from the database there are likely to be properties that expose information about your schema and persistence mechanism that are redundant from a client's perspective.
In summary there may be a limited number of cases where exposing the EF entities may be acceptable but typically I would design for change and implement some sort of pattern where you map your EF entities to light-weight "persistence-ignorant" POCOs at your repository layer. EF 4.0 does provide the ability to code up a context that returns POCOs, but on my current project we use the codegen'd context and then use automapper to map the EF entities to our data contracts. Outside of the repository layer nothing is aware of the EF entities and I feel this allows for a more maintainable and robust design.
My colleague has found himself in an "interesting" situation. He is working on a Silverlight (2.0) prototype that needs to call existing web services in the enterprise and bind the returned data to data-display controls. The thing is, the web services return .NET DataSets (they are not about to change existing implementations) and Silverlight does not natively support DataSets.
What would a good workaround be? I was thinking an adapter pattern but do not know if middle-man web services to carry out transformations would be a very good idea. Could be tedious if there are many existing web services.
AFAIK, when a .NET web service returns a DataSet, it returns its XML representation (which is pretty friendly). The fact that a .NET client can consume the DataSet directly only abstracts the fact that an Xml Serialization-Deserialization is taking place.
So I would manually query the web services you require, observe the generated XML, and then parse it in the client side.
Another possibility is to take advantage of the fact that Web Services use the standard XML Serializer, so you could create the C# classes from the returned schema and then let the XmlSerializer automatically handle it. I'm not sure if the code generated by the XSD.exe tool will be Silverlight friendly, but it is worth giving it a shot.
Try the following: http://silverlightdataset.net
The dangers and general nastyness of Datasets eh. I would use a generic proxy that is responsible for consuming the webmethod and transforming the dataset into xml/json
Yup, silverlight ds is a great solution, they even have relationships built into it