Enterprise Library or Entity Framework [closed] - c#

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
which one is more useful for a project with a huge database
useful means :
Insert and delete and update fast
select a lot of rows fast
update database structure easier
programmer friendly
, .....
we have considered that database implement is in the best situation of indexing and ....
thanks

From http://forums.asp.net/t/1647988.aspx:
DAAB is the Data Access Block provided by Ent. Lib.
They are completely different animals. The DAAB is a data access library (wrappers around ADO.NET), whereas the Entity Framework is an Object Relatonal Mapper. They don't do the same thing. If you want to use a data access library, Microsoft would recomend the Entity Framework. If you want to use an ORM. they would recomment EF.
Other similar question on here:
Entity framework vs enterprise library
General Questions about Entity Framework vs. Enterprise Library & a few others

Related

The right ASP.NET boilerplate best practice [closed]

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 4 years ago.
Improve this question
I just found about the ASP.NET boilerplate framework for ASP.NET Core applications. The boilerplate is cool, it has all the necessary structure we need in order to create a SOLID proof web application.
My question is that, as per the site I have to create entity models in .Core project, and Dto's in Application project but as I can see these Question, and Answers are different entities but they kept both of them in the same folder and same namespace.
It does not look like a good practice, can anyone tell me is it wrong to keep these related entities in the same namespace/folder or it's ok to do so?
You can locate entities/services into any namespace. This is not related to the framework actually.
Question/Answer application is very simple project where there are just 2 entities. I thought that Question is aggregate root and answer is a child entity (they are a single aggregate together). This is why I put them into same namespace.
I suggest to follow "namespace per aggregate" principle, but "namespace per entity" is also fine.
BTW, #Dongdone, AspNet Boilerplate is completely open source & free. We have a another product, AspNet Zero (https://aspnetzero.com) that is commerical and developed on top of the ABP framework. But that does not make the ABP framework a paid tool. It's absolutely open source & free.

C# Optional params for build sql string best way [closed]

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 5 years ago.
Improve this question
i'm trying to see which is the best way or practise for sql string optimizations in c#, mssql. What i'm trying to do is like a crud system where we send the necessary required params such as db name and table and after we have the conditional, for example if its a remove action, we will have an where condition and it can contain more than 1 param so what i wanna know is get the whole params.
Should i accept an array with those conditions or what i must do.
Thanks
Not exactly an answer to your question but you should consider using ORM tool like NHibernate.
With NHibernate, you can accept QueryCriteria or ICriteria from outside world which will do the query accordingly.
Be warned that this will be big change in your application and NHibernate have steep learning curve.
There are also simple micro-ORMs available like Dapper. With it, you can implement Repository pattern by creating Data Access Layer. Refer this link.

Entity Framework User and Role Management [closed]

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 7 years ago.
Improve this question
I have a Visual Studio solution which contains several projects :
Domain classes
Data access layer - which contains DB context
MVC application.
The MVC application by default uses existing classes for user management and it also has his own ApplicationDbContext. In this case we have two DB contexts.
What is your experience regarding the user management ? Would it be better if I create my own classes for user management and place them to the Domain Classes project. I think it would be much easier latter for maintaining and in this case there will be only one DBContext. Another possible problem can be relations between existing ApplicationUsers(from the MVC project model) and classes from the Domain Classes Project. Or maybe to move the ApplicationUser class definition to the DomainClasses project ?
I highly recommend MembershipReboot. You have the option of using its built in UserAccount or using your own.
On a side note Brock is part of Thinktecture. In one of the asp.net stand-ups it was mentioned that the team may just recommend a 3rd-party identity provider instead of role their own. That was my understanding but maybe I am just being hopeful. I think it was this one https://www.youtube.com/watch?v=CMTd5yS-yFE&list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF&index=2 but don't hold me to that.

winform or wpf for entity framework? [closed]

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 8 years ago.
Improve this question
I want to know which one is the best natural choice while working with SQL and Entity framework, c# Winform or the WPF? Assume that skilled resources available for both the technologies (Winforms and WPF).
Entity Framework doesn't care which UI technology you use on top of it.
There's no natural choice - use whatever you're comfortable with and whichever works for your needs
After working with both, I strongly recommend WPF, since it gives you a far better code/UI separation. Using MVVM makes the code more readable and easier to maintain (and read).
SQL and EF don't care how the layers above are implemented, it's your choice alone.
EF not dependand any one like if you used winfrm or WPF. but there is a difference between winform and WPF.
if you want to know then you can use the mentioned link Click here
If you want better Presentation of your application then I would recommand you to go with WPF.

How to Migrate from Plain Entities to Self-Tracking Entities? [closed]

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 6 years ago.
Improve this question
I'm working in a project that uses .NET Entity Framework 4 with EntityObjects. Since we have found that we need to evolve into self-tracking entities for the remaining modules that haven't been implemented, I want to ask this:
1) Can we delete the existent plain entities and regenerate self-tracking entities from the database without modifying our currently written code using them?
2) If the answer of 1) is 'yes', is that easily done? How would you proceed to migrate from the first scheme to the second?
Change the namespces of your existing POCO classes to the one you expect EF will generate and so that your references will be updated.Then delete old POCO classes and generate EF classesThen compile your solution
By plain entities i presume you mean POCO's. You probably need to delete the POCO classes u wrote or generated and set the build action of the edmx file to EntityDeploy.
Hope this helps.
You just have to remove any old T4 you may have used (if you used POCO T4), and add new self tracking POCO T4 from your model.
It should be enough to work.

Categories