0

I was trying to investigate the use of EF4 for my project and I faced this "interesting" problem.

Creating the edmx, there is an easy way to connect the entities to a user interface component (DevExpress GridView for instance) passing through the EntityDataSource.

Question: Do you think is there a better way to bind my entities to controls?

Now as a client specification I would be happy to interact with the database through stored procedures (for update, insert, select, delete) limiting then the power of EF, but still it would give me some benefits.

Question: Is there a way to use a select stored procedure as it is done for insert/update/delete and continue using EntityDataSource?

Question: Do you think it is a reasonable solution to populate the entities with database views in order to pilot the select and use the stored procedure mapping otherwise?

Thank you for your help and thoughts.

Mauro
  • 2,032
  • 3
  • 25
  • 47

1 Answers1

1

The first question is somewhat open in nautre, and rather dependent on the controls you are using, and the design pattern (if any) that you are trying to adhere to. From a development perspective, if you are Unit Testing you should always consider seperation of concerns, and how tightly you want to bind your controls to your 'domain'. Is this an ASP.NET application?

The second question is quite common, especially in enterprise scenarios where you have security concerns and serious DBAs (!). You CAN implement select stored procedures. I'd suggest reading the post found here.

As for the third question, again it is possible to use views in Entity Framework. There are several articles and pitfalls, I'd certainly check this article first as well.

2 and 3 really come down to the clients requirements. On my current project, we are using stored procedures for create, update and delete operations, whilst allowing direct select access on our tables as necessary. This is effective as it allows you to use the native power of EF and LINQ in terms of dynamic queries. Again, this suits our requirements, but may not suit yours!

EDIT:

I just wanted to provide a couple more links regarding your last comment, as they deal more explicitly with EntityDataSource. The relevant SO article is here, and it links to a nice article here, which should help you.

EDIT:

One more option is to add a defining query to control how EF performs the select. See here.

Nick.

Community
  • 1
  • 1
Nick
  • 2,285
  • 2
  • 14
  • 26
  • Thanks Nick, one of the best edited answer I have ever read. The application is an ASP.NET application, possibly with two flavors, web and winforms. This scenario would probably lead to a greater separation of concerns, but for rapid application development that the project leader is following, the direct link between EF and the user control via EntityDataSource has a GREAT appeal. – Mauro Jan 11 '12 at 15:20
  • On the first point, I would say: UI controls try to make you work with database-driven data more than with a proper Business Logic Layer. The post teaching how to create – Mauro Jan 11 '12 at 15:21
  • On the first point, I would say: UI controls try to make you work with database-driven data more than with a proper Business Logic Layer. The post teaching how to create custom SPs does not unfortunately fit 100% because it seems to me that it cannot be called from EntityDataSource. Am I wrong? – Mauro Jan 11 '12 at 15:26
  • No problem Mauro. You are spot on. It's the age old conflict between doing things in a Rapid Application Development style, and making that 'future proof'. I have done a lot recently with Patterns and Practices, and am not one for following those just for the sake of it. If your primary driver is RAD, then there is no reason you shouldn't plug into your EF directly. In your case, the only caveat is perhaps highlighting to your client that, at the point you look to expand into other UI capability, that might be made more difficult by 'tight binding' now. – Nick Jan 11 '12 at 15:33
  • At the end of the day, I've found that focus should always be on the business. If you are delivering a well crafted solution to them in a rapid fashion, then it's a good solution (usually! It's always possible to write 'bad' code I suppose). – Nick Jan 11 '12 at 15:35
  • I've also updated my response above to include some more appropriate content regarding EntityDataSource. – Nick Jan 11 '12 at 15:37
  • Well, your answer is super. Unfortunately I already checked that post and there is no solution to the problem of attaching a select SP to EntityDataSource. I'd say that the only solution up to now is using views. – Mauro Jan 11 '12 at 15:53
  • I totally agree with you on the "usual" necessity to craft a full middleware to achieve the best result. My concerns are only: to me these UI controls like DevExpress seem to push you binding to database sources more than creating a proper sound business logic... – Mauro Jan 11 '12 at 15:56
  • In my previous life I developed .NET applications from ground up, so I kinda know both worlds... :) – Mauro Jan 11 '12 at 15:57
  • I've added one more link which might prove useful :) I know exactly what you mean. We use the Infragistics controls, and often sturggle to adapt them to exactly the right technique. These controls tend to get you to 80% really quickly, but the last 20% is a nightmare! – Nick Jan 11 '12 at 16:16