5

I'm currently building a web application for my enterprise level business internship. This web application will track data from three different sources: a DB2 database, a SQL Dynamic database, and an existing API, and then marry them together.

I'm currently working on the SQL Dynamic side, and I was advised to use Entity Framework to streamline this process. From what I understand, EF is useful when creating local database contexts to perform queries against, generating SQL code, and when updating/inserting records to provide security and performance benefit. However, the SQL data that I need to marry will only be provided by a SELECT, and will be implementing a single stored procedure that will return the data I need.

I have already developed an API to access SQL stored procedures in C# (I was advised this would help them and myself greatly due to their DB infrastructure). I personally don't see the benefit of adding Entity Framework to this solution; in my view (which, take with a grain of salt as a result of my intern position), adding EF to this solution will only increase dependency on non-internal packages and increase complexity of maintenance in the future. I don't need to generate SQL code, and I don't need to insert records; I just need to pass parameters.

In a scenario like this, where I am passing parameters to a single stored procedure already housed in the SQL DB I'm accessing, where can Entity Framework benefit me? If it won't, are there any more convincing reasons I can provide to those above me to remove this dependency?

Improve this question
10
  • I'd agree on your reasons against EF, given the little I know about your requirements Some of the advantages of EF are in the way it can scale and 'migrate' data and schema changes, doesn't sound like you need to leverage that.
    – JᴀʏMᴇᴇ
    Jul 20, 2018 at 15:54
  • 2
    In terms of convincing reasons, I'd always want to justify reasons for introducing a technology rather than against. They're the ones who proposed the introduction of EF, so...why? What does 'streamline' mean? I assume they mean it's easy to set-up, but that's about it. Consider, though, you may still need an ORM (possibly look at dapper).
    – JᴀʏMᴇᴇ
    Jul 20, 2018 at 15:56
  • @JᴀʏMᴇᴇ I agree with this train of thought. I'm not entirely sure if I will need an ORM; the API I made converts results from each DB into standard .NET supported types, to make future marriage compatible. I don't, however, know if my application could be further benefited by ORM, and I will do some research. If that's the case, EF will likely be my only option due to policy.
    – nostalgk
    Jul 20, 2018 at 15:59
  • 1
    See here and here
    – Robert Harvey
    Jul 20, 2018 at 18:41
  • 2
    I just wanted to commend you for respectfully questioning the wisdom of your seniors. You may want to just directly ask them why they feel it’s worthwhile to add EF. Maybe they feel like the project will grow and want to set a pattern now. When in doubt, have a conversation. Software is 80% having conversations with customers & peers in my experience.
    – RubberDuck
    Jul 21, 2018 at 11:43

2 Answers 2

Reset to default
1

No. Its not worth adding EF if you are comfortable with SqlClient for your needs.

Although you can call sprocs and run your own SQL strings via EF easily enough, its not leveraging its features and it has a few quirks to trap the unwarey, which may trip you up.

In fact its arguable that its never worth adding EF. But lets leave that for another day.

Improve this answer
1

EF can certainly feel a little heavy at times. Since you are comfortable with writing SQL maybe a micro ORM like Dapper suits your needs better.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.