Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Can I Use Entity Framework 6 with .net 4.5 for a big project ?
In this project i have many solution in this project and some of them are in a fast communication with database like as Smtp with hug data communication
thanks
// edit for more details
i start a big project that it has five section
1- send sms with smtp that create huge request and overload on database for example in secound 1500 record insert and select
2- payment request
3- many other request ...
The default answer, is certainly yes. This is where all ORMs shine. In large systems where writing a data access layer is a big and error prone task.
As Steve McConnell suggests in his great book you should never make speculations about performance. Therefore, if you have specific performance concerns, you should try benchmarking.
If you want my opinion, between clear code and performance, I choose clear code. It will allow you to implement a more robust and maintainable system. Then, if you identify performance problems, you could make the necessary minor changes. This is my default rule.
Hope I helped!
Can I Use Entity Framework 6 with .net 4.5 for a big project ?
Yes
In this project i have many solution in this project and some of them are in a fast communication with database like as Smtp with hug data communication
Yes, although it might depend on your database design. And even then you could use Stored Procedures if necessary.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am beginner to .net core. And I am working on an enterprise application where there are multiple classes interfaces for multiple project inside a one solution. i know Entity Framework won't be a good idea if we are facing huge number of wrappers. But indeed its giving me efficiency of coding. On the other side of it Entity SQL has its own benefits.
But still want to really understand the best practice and which one to implement when it comes to Enterprise application knowing it will have number of classes, Data filtration, Generic Types, Flexibility, performance vise when querying DB.
Looking forward to get some really helpful understanding from experts. Thanks in advance.
TL;DR;
The "best practices" depends on the use case. Its a set of tools, not a silver bullet.
Sometimes EF works for your case, sometimes not. Sometimes you want a monolith, sometimes you dont.
Try, experiment fail and succeed.
Best practices regarding to techniques are irrelevant; implementation change all the time. So;
define functional requirements
define none functional requirements
do a PoC with some relevant loads etc.
At enterprise level consider these additional properties:
security
operational functionality
cloud / none-cloud
This is the best I can do, given your question.
Explain the case and we could give some direction; but its not a template fitted for all cases.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I would like to build a c# spa application using angular with real-time messaging signal-r. The signal-r should read the data continuously from a data source and publish the updated data to the user and store the data in a database as well. It should also enable the chatting of the users.The expected number of users is around a hundred.
For such application what should be the best architectural structure of the solution? Should I implement two (three?) projects, e.g. one for the web app and the other for the signal-r, running as two applications? Then, in this case, how can I do the messaging between the applications? Or should I implement a single project for all of these? It would be best if you can provide the pros and cons of these alternatives or provide any other option.
Start with one project.
For 100 simultaneous users, you aren't even close to worried about load. Any simple hosting plan would take care of it easily. If you get more, ASP.NET and SignalR work just fine behind a load balancer (though certain operations can get more complicated).
A properly architected application won't be difficult to split into multiple processes in the future if it ever came to that, and doing so now is just adding mounds of complexity for no appreciable benefit. This goes double since it sounds like you are just starting out.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm about to develop some LOB applications using VS2012, WPF, Sql Server Express 2012, Unity, Prism.
I don't have legacy applications to care about.
Is it ok if I choose the Model First workflow for my upcoming projects, are there some important benefits in the Code First workflow that I would not be receiving?
If there's any that I could not overlook, then could I start with Model First and then switch to Code First?, it happens that I'm more confortable designing databases with the designer than by code, this is the main reason for this question.
If you're more comfortable working with databases first, I would go down that route. This question has a lot of pros/cons for each.
I've recently used code first for a project and I regret that decision. Although it is incredibly powerful, it was an unnecessary learning curve and ultimately took far too long to setup a simple schema.
If you want to learn how code first works, and time isn't an issue, then you may as well go for it. Else, what do you really have to gain from it?
Ultimately though, if you're developing it and you already have a sufficient skill set in one of these, use it.
I have created WPF applications using code first and MVVM patterns + DI (though not Prism).
It took a while to convince me to move away from the edmx models, but I've found Code First to be a much cleaner approach, with no apparent downsides.
I think you could easily move to model first from code first, though you probably wont need to. I haven't tried it - you might need automapper.
I have successfully taken existing dbs and moved over to CF though it is a bit messier.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Subjective question I know....
We have an existing application that has around 20 components that connect to a database. We are now clustering the application to increase scalability but we're hitting some limits where every process having a small connection pool is resulting in many connections to the DB. There would also be some interesting options for caching across our cluster if we could centralise connections.
My question is are there any low cost/risk options to refactor our solution from utilising SQL connections directly to a middle tier? Is the pain of this worth rewriting a full unit of work + models style application tier and refactoring all our database connections into the WCF business logic calls?
As a longer term solution refactoring to a middle tier would be helpful in that any common connection handling logic can be centralized. One common reason for the multiple connection problem is that connections are not disposed of correctly but it's speculation without looking at the code.
See the following from the sql support team for diagnosing multiple connection issues http://blogs.msdn.com/b/sql_pfe_blog/archive/2013/10/08/connection-pooling-for-the-sql-server-dba.aspx
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm working on a project that we're using .NET MVC 3 and EF 4. The website is growing and there are a lot of tables. So, the table designer of Entity Framework too much CPU usage t open and add new tables. What are my options? What can I do?
For larger models, I think the designer approach is less desirable. If you can, consider refactoring (one bite at a time?) to a code-first approach; this will allow you to keep using current technology. I have a project with ~650 entities working perfectly fine, but I can't imagine loading a .edmx designer with ~650 entities (without pulling my hair, that is).
All in all, it's not EF that's "heavy" - it's the designer.
Starting with Visual Studio 2012, you can now split your Entity Model into multiple diagrams. This'll reduce the diagram complexity a lot.
See
http://msdn.microsoft.com/en-us/magazine/jj721589.aspx
http://msdn.microsoft.com/en-us/data/jj519700.aspx
If you database operations are large in general you may consider not using EF and use raw ADO.NET instead. EF boils down to ADO.NET at the low level anyway but using ADO.NET right away will improve performance.
Moving to a code first architecture is definitely something to consider for the long term. For the short term, you also might be able to break your model up into multiple design contexts. You can start this by identifying areas of the application that only use a subset of the tables. Then create a separate data context that only includes those tables. You can keep the existing omnibus context around while you're working on this to avoid breaking legacy code. You can add as many data contexts as you like, but I would create each one in a separate folder (and therefore a separate namespace) so you don't have to worry about name collisions.