Well I am new to this ORM stuff. We have to create a large project. I read about LINQ to SQL. will it be appropriate to use it in the project of high risk. i found no problem with it personally but the thing is that there will be no going back once started.So i need some feedback from the ORM gurus here at the MSDN. Will entity framework will be better? (I am in doubt about LINK to SQL because I have read and heard negative feedback here and there)
I will be using MVC2 as the framework. So please give the feedback about LINQ to SQL in this regard.
Q2) Also I am a fan of stored procedure as they are precomputed and fasten up the thing and I have never worked without them.I know that LINQ to SQL support stored procedures but will it be feasible to give up stored procedure seeing the beautiful data access layer generated with little effort as we are also in a need of rapid development.
Q3) If some changes to some fields required in the database in LINK to SQL how will the changes be accommodated in the data access layer.
When it comes to Linq-to-Sql vs Entity Framework, I strongly suggest to use Entity Framework. With the release of .NET 4.0 and VS2010, Microsoft added soooo much goodness in Entity Framework(EF) 4.0. Let me just mention a few points: POCO and NTier support (this means that you can have a separate library with your simple entity classes and of course EF will still be aware of them), Lazy Loading, Sql query optimizations...Also you can let EF to generate your entities (and you have the option modify the T4 generation template) or you can create them by hand if you need more control. Also, if you app will indeed be large, with EF 4, now you can separate your layers quite nicely(you can create your Mocks fo testing etc...). I'm not a web developer, so I cannot give you any hints on mvc2 on this matter.
q2-q3) - in EF you can have precompiled queries - IF you observer later on that query performance is not quite what you need. This will speed-up things quite a bit. If you plan to use EF and if you add a few changed to you database, you can easily update your model with a click.
I know I babbled too much on EF and not Linq to sql :), but hey...I believe this suits way better on your needs and you should definitely check it out for this project. Also, I don't know how much Microsoft will add features / invest in LinqToSql in the future.
Cheers,
ok precompiled queries that certainly is catching my attention.
Related
I'm looking at the ProjectTracker CSLA example solution and it has projects for DAL, EF implementation of DAL, and a project for the business objects/rules/etc.
I understand it's good practice to split logical separations in to projects, buy my concern is is there really a problem putting the DAL and EF into the business assembly?
It seems that build time is most affected by the number of projects.
The app I'm working on would likely have 18 or more projects if i followed the examples layout.
I know i can make multiple solutions to help mitigate this, but I don't want to go down this path right off the start.
Thanks.
Multiple projects are recommended, and are necessary to get the full benefit of CSLA and its n-tier architecture.
If you know beyond the shadow of any doubt that you will never need n-tier deployment, never need advanced security, never need increased scalability, and generally aren't looking to build an enterprise level app, then you can use fewer projects.
In fact, if you are building an app that you know you'll deploy as a 2-tier app then you can put the business classes and data access classes directly into your UI project along with the UI code.
Is that a good idea? No.
Will it work? Yes.
To piggy-back on Rocky's answer, the company I work for uses CSLA, and we originally had all DAL code in our business classes. We were on Oracle 10g as our dbms at the time, but wanted to switch to SQL Azure (and we had a pretty big system upgrade and schema changes simultaneously). So, we did the following:
Implement the DAL interface as a project
Implement 2 DAL projects, one each for Oracle and SQL (actually 3 w/ a mock db, but that was more for proof of concept)
This let us test the conversion in both databases simultaneously. If we had started with the DAL project to begin with, this would have been a lot easier to accomplish.
Long story short, it may take more time, but unless you're positive of all of Rocky's points, it's worth it.
Is there any open source projects or demo projects using Linq2Sql as primary data layer for accessing and updating all its data?
I am working in a project(asp.net webapp) which has Linq2Sql in DAL. We realized that half way through the project our design is not properly working out. I would like to see how Linq2Sql is being implemented in multilayered project. Any reference or guidance would would be good to.
I am already aware that Entity Framework is preferred way going forward but this project is mostly done in Linq2Sql, so we would like to finish it out.
a year ago, when I tried asp.net MVC I used nerd dinner to learn it, if I remember correctly, it's using linq2sql
I am at a company that does not understand the concept of using frameworks and the benefits of them. I have tried to explain that it provides structure and organization but the people I am trying to explain to are still a little fuzzy about it. In your opinion, what is the best way to describe a framework in the most simplest terms and how it could overall benefit a company to transition their code from procedural and spaghetti code to a nice organized framework?
Thank you for your time.
I guess the best explanation I can think of for using a framework are to standardize your design process and save yourself a lot of effort as your code-base grows. Not to mention that a lot of work can be taken care of for you by the framework (which could save hours of coding). A framework can give you all the parts you need to build your application, you just have to assemble them.
The best reasons I can think of for using a framework are:
Code reuse -- If you try and follow the design of the framework you can save yourself a lot of coding time. However, some frameworks do require a time investment to master.
Encapsulation -- You can change the underlying implementation of different parts of the framework in a way that doesn't require a lot of code rewriting.
Extendability -- You can extend the code of the framework to add features you need and if you are careful about your design, you can reuse these features too.
I'm sure there are many other good reasons, but I'm sleepy.
EDIT: A good example of the benefits of a framework can be replacing the database adapter with another ie. switching from mysql to postgresql. This could be awful with functional programming but a framework could make this transition very easy.
Your coworkers most likely already use libraries, which one could define as code that exists outside of your project, and is meant to used in many projects.
A framework is like a library, but usually has other featues, such as
It might enforce changes to your code. For example, you wouldn't replace one method of your WebForms project with a call to the ASP.NET MVC framework - the entire project would be written differently to conform to the framework.
It might restrict the universe of applications that you can write. For example, you might be using a CRUD generating framework that lets you make data entry applications, but wouldn't let you make a video editing application.
However, a framework will usually give you a lot of value in return.
Let them do as they like ,first.
then pick up their shortcomings and
finally generalise your framework to avoid procedural code.
I'm going to concentrate on only a part of the question:
In your opinion, what is the best way to describe a framework in the most simplest terms
Framework == Library + Inversion of Control
I'm thinking about using Linq to NHibernate in an upcoming project, so I'd like some feedback about it. I found this identical question asked in February, and it seemed that Linq to NHibernate was not very mature at this time... Has it improved since then ? Has anyone used it in real life applications ?
Thanks for your feedback
PS: please do not close as duplicate : the existing question is almost 1 year old and I'm asking about the current status of the product...
Ayende (one of the more vocal contributors to NHibernate) noted in a blog post this week that NHibernate's LINQ support is somewhat lacking (as compared to Microsoft's Entity Framework). I don't believe much has changed in the last year in the production code base. He does note that the next version of NHibernate will improve on this support.
Linq to NHibernate is OK most of the time, but you need a fallback option.
I use it in a large project as the default query language as I expect it to become more mature soon, and I especially like its agnosicism towards the underlying framework - you can use it if you know the basics about O/R mappers and Linq; you don't need to be super-familiar with NHibernate in special. The other options for writing queries, especially the criteria query API, pose some extra learning effort. For most of the features, complex queries are not required, and Linq to NHibernate is good for some Wheres and OrderBys.
However, there are still odd cases of failure where the query itself is OK, but the generated SQL just is not. In these cases I don't spend time examining what's up, but fall back to the criteria query API.
Please refer to http://nhibernate.info/blog/2009/12/16/linq-to-nhibernate-progress-report-a-christmas-gift.html for the latest info
Hey I follow Steve Strong, as from what I understand, he is the main developer of this project.
here is his latest post "Using the new Linq to NH Provider and migrating from the old one " http://blogs.imeta.co.uk/sstrong/archive/2009/12/16/824.aspx note it was just after the NHForge latest post on this topic.
To get this version look at the HornGet link provied in the post
I looks really promising
bones
We are using an oracle database in a project. Most of the tables represents classes or objects in the application. The application currently doesn't have a substantial amount of documentation. I am using StarUML to make up some class diagrams and such for other developers on the project to increase their understanding of the overall project. Using the database tables as a starting guide, and then making modifications to the diagrams as needed would be the absolute easiest and quickest way to get these set up. Is there any free applications that could assist me in pulling the schema out of the Oracle database and create class diagrams from them? Currently, there are 98 "objects" or classes closely modeled in the database and to create these all in a modeling application from scratch would be very time consuming.
You don't say what your target language is.
You can use Hibernate to generate schemas from an object model and mapping.
Middlegen is a tool that can create Java classes from schemas. Maybe those will help.
A 1:1 object-to-table mapping isn't always the best way to do things. It's hardly object-oriented. I'd view it as a starting point only.
I looked (briefly) through the StarUML documentation and don't see any way to import a database definition, so I'm not sure how you do this, sorry.
If you can find a way to get the data into StarURL, you could use Oracle's free SQL Developer tool to get the table definitions out as DDL or XML.
I know that Microsoft's Visio tool (Pro & Enterprise editions) can read selected tables from your Oracle database and generate models from that, but it ain't cheap. I really like Allround Automation's PL/SQL Developer as a reasonably-priced IDE targeted at programmers (vs DBAs) and I know that will generate diagrams locally. But I'm not sure it can save the metadata in a form you could use in StarUML.
Good luck,
-- Stew
It's a shame you didn't bother to respond to replies to your own question. Or am I misunderstanding the standard practice here that people just give points and move on?