When I connect to a database via VS tools it offers to automatically generate the DataSet code for my DB. I didn't work with databases in VS before that way, so can anyone tell, is that autogenerated code is applicable for a serious project, that will need to be maintained later? Or it's good only in simple and common cases and it's better to write my own classes for database interaction?
I would recomand to use ORMs like Entity Framework or Nhibernate
ORMs allow you to abstract from Data base you will work with POCO objects. that will help you in maintain and in design your project.
Related
I am currently about to start out on a project to convert a legacy access front end application using MSSQL backend database to WPF using the MVVM pattern.
The database has around 300 tables so it will need to use and ORM tool to generate the POCO classes using database first driven design.
I have recently receiving some mentoring for the project and nHibernate has been recommended as the ORM over Entity.
Looking to find out your recommendations and whether we should be looking to Entity or another ORM as opposed to what is possibly just the one that the mentor has experience using?
Thanks in advance,
I'm using NHibernate everywhere. On .NET Core, on .NET Framework, since 2009. Only some projects that are not permitted use of NH i've used EF or other orm or some like this (Linq for SQL or DAAB stuff).
NHibernate provide more control, more configuration spots and more features instead EF. It's my recomendation in all scenarios that be use a ORM. Dapper solve some questions too.
But if i have NH i don't need Dapper because we have some types of operate with database.
More options, more responsability. NHibernate is more complex. Needs a deep drive into your complexity to understand how give best performance and approach to solve any kind of database interaction. Do you do more, but you must know to do.
I am using Visual Studio 2015 with Entity Framework 6 and .NET 4.5.2 for a WinForms application. I am currently working on adding reports to my project. I thought about adding the classes which return DTO collections intended for reports to my DataServices section. I decided not to because all classes in my DataServices section currently use my DAL to provide CRUD operations through repositories. My classes for reports will only return read only DTO collections. Since my report DTO classes will not use the typical repository methods (i.e. Add, Update, Delete...) I decided to create a new folder in my project called ReportServices. I have therefore placed my report class named RequestReports (this is for my Request model entity and will return a RequestDetailDto collection) in that folder. Below is a picture of how I have things setup now:
I am not sure if the way I have it setup is the right thing to do. One other way might be to just scrap the idea of a reporting section and mix the reporting classes in with the other data services which use repositories. If I do this, then I would simply not implement the repository methods of add, update, delete for the report classes. I would only implement the get operations for the reporting classes of FindByID and FindAll. Is this really the way to go?
So my question is, "Where should the classes which retrieve information for reporting purposes be placed in a Visual Studio project of a layered design?"
Thanks in advance.
I recommend creating a separate project altogether for reporting. Keep the reporting model and data access separated from your main domain, don't use the same Repositories. Different purposes means different efficient ways of fetching data. It will also pave the way for the option of storing reporting data in a distinct database.
You might want to check out the CQRS approach, it brings a lot to the table on these issues.
What's the recommended way of creating a Data Access layer in real-life ASP.NET MVC applications? Is it EF? Ef Code First? NHibernate? Any other idea?
Thank you & regards
There is no recommend way.
I prefer EF Code First for doing this because
the Sourcecode is very clean and easy to read
It is easy to simple change the connectionstring and generate a new database if not already exists
easy to migrate your Database if your Model has changed (no need to recreate the Database) using EntityFramework.SqlMigrations
if your Database already exists you can use the Entity Framework Power Tools to generate the Models and Database context from your existing Database
It all depends of your need:
NHibernate is a more mature ORM with a big community
Entity Framework is now getting very well supported and you can find also great information (check Julie Lerman blog)
Both support code generation from database.
Code first: allows you to create your database schema from your domain models. This is great if you don't want to bother with database. NHibernate can do it also.
To help you decide which way to use Entity Framework
Source
There are many other great ORM:
Subsonic
Stackoverflow's ORM Dapper if performance is an important criteria there is a small benchmark on the site
If you're partial to the MSFT tooling and wanting to be "modern", then EF Code First is probably the place to start. One example worth perusing: https://github.com/NuGet/NuGetGallery .
I like to use Model First because it allows me the most freedom to design and implement in my opinion. It also makes it very easy to change the database design.
There is none, stackoverflow is full of people who have gone down the various routes, so you can get help no matter which choice you make.
Best advice, try doing a few small exploratory webs using a couple of approaches which seem to stand out.
The MVC gurus (the people who wrote MVC) at MS all seem to use Entity Framework at the moment. having said that you can use any ORM (or really any data access tech you want) as MVC doesnt actually specify anything at all about the way you access data
Try LINQ, most MVC products I see make use of LINQ.
Is is it possible to use l2s in model first approach?
Here's the think i want to achieve:
I want to write my app in TDD manner, so I want to write some domain specific objects first and then base on that generate database model.
One solution is to l2s as DAL but and map linq generated entities to my custom domain objects(I Rob C. in Storefront app did), but i would like to use l2s objects directly
Other solution is to use T4 Toolbox: LINQ to SQL schema generator but it is based on visual team system IDE, which I don't have access to
Last solution i found is to use Close2Poco
Have you tried any of this solutions ?
Is it easy to achieve with l2s?
P.S.
Sorry for my english
Not with the current version. Visual Studio 2010 will support this. There's currently a preview release available from Microsoft here:
http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx
Does anyone know of a simple WPF or Silverlight framework which enables you to e.g. define some database tables in e.g. SQL Server compact database and then the framework automatically creates the Window classes etc. which allows a user to login and edit that data?
I'm not looking for a complicated MVVM pattern example, it can be hard coded, it should just save the developer the time of creating all the CRUD code and forms and authorization necessary for users to edit the data. The developer could define 10 database tables, run the code generation, and then be pretty much 80% finished with any simple database application he wanted to make.
All of that would be generic code so I would think some framework like this would exist or someone would be working on some open source project like this already.
Does anyone know of a framework or tool like this?
It's not Silverlight, but ASP.NET Dynamic Data sounds like it would do what you're asking. It provides a web-based front end for editing database tables.
I've used it for a small project and you can literally have it up and running with CRUD functionality within an hour.
maybe you should take a look at the Sculpture project. There might be something you are looking for.
Since you cannot have direct connection to a database server with Silverlight, you should look at a .NET data access framework using the regular .NET Framework thru a Web Service.