CodeSmith از انتشار PLINQO 5.0 خبر داد.

[mehdi.mousavi]

سلام.

PLINQO 5.0 یک Open Source Library ی LINQ to SQL هستش. برای دریافت PLINQO میتونید به اینجا رجوع کنید (http://plinqo.com/download.ashx). توضیحات بیشتر رو در این سایت (http://plinqo.com/default.aspx) مطالعه کنید. - منبع (http://techblog.ginktage.com/2010/06/codesmith-announces-the-plinqo-5-0-release/)

موفق باشید.

[nofilter]

سلام
جالبه ولی فعلا به کار ما نمیاد.

[Alireza_Salehi]

هیچ کدوم به LINQ مایکروسافت نمیرسه...

[mehdi.mousavi]

هیچ کدوم به LINQ مایکروسافت نمیرسه...

Wow... شما به این سرعت Framework مزبور رو آزمایش کردید و در موردش قضاوت کردید؟ هوووممم... منم یه زمانی برای مایکروسافت و محصولاتش میمردم، اما حقیقت اینه که نباید چشممون رو روی پیشرفتهایی که بیرون از مایکروسافت رخ میده ببندیم...

موفق باشید.

[Alireza_Salehi]

Wow... شما به این سرعت Framework مزبور رو آزمایش کردید و در موردش قضاوت کردید؟ هوووممم... منم یه زمانی برای مایکروسافت و محصولاتش میمردم، اما حقیقت اینه که نباید چشممون رو روی پیشرفتهایی که بیرون از مایکروسافت رخ میده ببندیم...

موفق باشید.
خیلی ها مدعی نوشتن فریمورک ORM هستند ولی به آن سادگی و ظرافت که در C#‎‎‎ از LINQ استفاده می شود در جای دیگری هنوز ارائه نشده است.

در ضمن در مرحله اول نیازی به تست نیست ، نمونه هایی را خود سایت گذاشته که در نگاه اول اصلا آن چیزی نیست که در C#‎‎‎ دیده می شود. ضمن این که lINQ در C#‎‎‎ محدود به دیتابیس نیست، در حالی که بسیاری از این فریمورکها محدود به دیتابیس هستند و شیوه نوشتن کوئری های آنها نیز به صورت تابعی است نه به صورتی که در سی شارپ امکان پذیر است.

اما بعید نیست برخی از این فریمورک ها سرعت و امکانات بیشتری در عین راحت نبودن کاربردشان ارائه کنند.

بنده برای محصولات مایکروسافت نمیمیرم، کاملا هم مطلعم در دنیای نرم افزار چه خبره.

در همان بخش Getting Started (http://plinqo.com/getting-started.ashx) سایت این فریمورک اگر مطالعه کنید چندین قابلیتی که در LINQ سی شارپ هست دیده نمی شود. البته از قابلیت Caching ش خوشم اومد ولی باید تست بشه.

[mehdi.mousavi]

خیلی ها مدعی نوشتن فریمورک ORM هستند ولی به آن سادگی و ظرافت که در C#‎‎‎‎ از LINQ استفاده می شود در جای دیگری هنوز ارائه نشده است. در ضمن در مرحله اول نیازی به تست نیست ، نمونه هایی را خود سایت گذاشته که در نگاه اول اصلا آن چیزی نیست که در C#‎‎‎‎ دیده می شود. ضمن این که lINQ در C#‎‎‎‎ محدود به دیتابیس نیست، در حالی که بسیاری از این فریمورکها محدود به دیتابیس هستند و شیوه نوشتن کوئری های آنها نیز به صورت تابعی است نه به صورتی که در سی شارپ امکان پذیر است. اما بعید نیست برخی از این فریمورک ها سرعت و امکانات بیشتری در عین راحت نبودن کاربردشان ارائه کنند. بنده برای محصولات مایکروسافت نمیمیرم، کاملا هم مطلعم در دنیای نرم افزار چه خبره. در همان بخش Getting Started (http://plinqo.com/getting-started.ashx) سایت این فریمورک اگر مطالعه کنید چندین قابلیتی که در LINQ سی شارپ هست دیده نمی شود. البته از قابلیت Caching ش خوشم اومد ولی باید تست بشه.

سلام.
سال قبل، مایکروسافت تصمیم گرفت LINQ to SQL رو بدلیل وجود Entity Framework به حاشیه ببره و این باعث شد بسیاری از برنامه نویسها صداشون در بیاد. بر اساس گفته Jeffrey Schwartz، مایکروسافت دیگه قابلیت جدیدی به LINQ to SQL اضافه نخواهد کرد و تمرکزش رو روی EF گذاشته.

توی چنین شرایطی، این سوال مطرح شد که "پس چه کسی LINQ to SQL رو از این پس توسعه میده و پیش میبره و قابلیتهای جدیدی به اون اضافه میکنه؟" پاسخ PLINQO بودش... اینجا تمرکز فقط روی LINQ to SQL هستش و این مساله ارتباطی به LINQ to xxx نداره که شما می فرمایید LINQ در C# محدود به DataBase نیست.

فکر میکنم شما PLINQO رو با EF مقایسه کرده اید که این سوء تفاهم پیش اومده...

موفق باشید.

[Alireza_Salehi]

سلام.
سال قبل، مایکروسافت تصمیم گرفت LINQ to SQL رو بدلیل وجود Entity Framework به حاشیه ببره و این باعث شد بسیاری از برنامه نویسها صداشون در بیاد. بر اساس گفته Jeffrey Schwartz، مایکروسافت دیگه قابلیت جدیدی به LINQ to SQL اضافه نخواهد کرد و تمرکزش رو روی EF گذاشته.

توی چنین شرایطی، این سوال مطرح شد که "پس چه کسی LINQ to SQL رو از این پس توسعه میده و پیش میبره و قابلیتهای جدیدی به اون اضافه میکنه؟" پاسخ PLINQO بودش... اینجا تمرکز فقط روی LINQ to SQL هستش و این مساله ارتباطی به LINQ to xxx نداره که شما می فرمایید LINQ در C#‎‎‎‎ محدود به DataBase نیست.

فکر میکنم شما PLINQO رو با EF مقایسه کرده اید که این سوء تفاهم پیش اومده...

موفق باشید.
اتفاقا چون عملا درگیر استفاده از جنبه های مختلف LINQ بوده ام (به عنوان یک برنامه نویس دات نت)، به نظرم EF هنوز آنقدر تکمیا نشده که بخواهد جای LINQ را بگیرد.

قبلا پروژه ای بود که بدون LINQ ما آن را پیاده سازی کرده بودیم، جنبه های مختلفی داشت از ارتباط با دیتابیس (ORM) و ارتباط با اشیاء و XML ، و در محیط های مختلفی اجرا میشد (وب ، ویندوز و موبایل) هر کدام این بحثحا ابزار خاص خود ر اداشت و پیچیدگی های خاص خود را، ضمن این که ارتباط بین این بخشهای نامتجانس نیازمند لایه بندی ها و مسائلی بود که زمان زیادی می گرفت.

ابزاری به نام LINQ که قابلیت ارتباط به همه آنها را بایک ابزار واحد و بسیار ساده چه از لحاظ پیاده سازی و چه از لحاظ خوانائی داشت معرفی شد و کمک بسیار بسیار زیادی به توسعه پروژه ما و کیفیت برنامه کرد، ضمن این که قابلیت توسعه آن واقعا بسیار ساده تر و کاراتر از ابزارهایی مثل DataSetبود.

من بعید میدانم مایکروسافت حرکتی رو به عقب انجام دهد و چنین ابزار مفیدی را حذف کند، بلکه اگر ابزار جدید تری بکار بگیرد قطعا در تکمیل آن خواهد بود. و اگر جایگزین آن باشد حتما قابلیت های مفید آن را خواهد داشت.


به نظر من در حال حاظر مجموع امکانات ویژوال استودیو برای ORM ، امکانات زبان سی شارپ، شیوه استفاده از LINQ، پردازش موازی و ... به نظرم خیلی جلوتر از EF قرار می گیرد. EF حداقل از نوع مایکروسافتی آن جدید است و تازه در حال تکمیل و معرفی است. هر چند ORM که LINQ معرفی می کند کمبود هایی نسبت به EF دارد. و در واقع دلیل آمدن EF همین کمبود ها است.

این مطلبی است که مایکروسافت در سال 2006 گفته:

When one takes a look at the amount of code that the average application developer must write to address the impedance mismatch across various data representations (for example objects and relational stores) it is clear that there is an opportunity for improvement. Indeed, there are many scenarios where the right framework can empower an application developer to focus on the needs of the application as opposed to the complexities of bridging disparate data representations.
A primary goal of the upcoming version of ADO.NET is to raise the level of abstraction for data programming, thus helping to eliminate the impedance mismatch between data models and between languages that application developers would otherwise have to deal with. Two innovations that make this move possible are Language-Integrated Query and the ADO.NET Entity Framework. The Entity Framework exists as a new part of the ADO.NET family of technologies. ADO.NET will LINQ-enable many data access components: LINQ to SQL, LINQ to DataSet and LINQ to Entities.
This document describes the ADO.NET Entity Framework, what problem spaces it is targeting and how its various components address those problems.

http://msdn.microsoft.com/en-us/library/aa697427%28VS.80%29.aspx

و این مطلبی که الان می گوید:

The Entity Framework is a set of technologies in ADO.NET that support the development of data-oriented software applications. Architects and developers of data-oriented applications have struggled with the need to achieve two very different objectives. They must model the entities, relationships, and logic of the business problems they are solving, and they must also work with the data engines used to store and retrieve the data. The data may span multiple storage systems, each with its own protocols; even applications that work with a single storage system must balance the requirements of the storage system against the requirements of writing efficient and maintainable application code.
The Entity Framework enables developers to work with data in the form of domain-specific objects and properties, such as customers and customer addresses, without having to concern themselves with the underlying database tables and columns where this data is stored. With the Entity Framework, developers can work at a higher level of abstraction when they deal with data, and can create and maintain data-oriented applications with less code than in traditional applications. Because the Entity Framework is a component of the .NET Framework, Entity Framework applications can run on any computer on which the .NET Framework starting with version 3.5 SP1 is installed.

http://msdn.microsoft.com/en-us/library/bb399567%28v=VS.100%29.aspx

واین یک اظهار نظر در مقایسه این دو:

LINQ to SQL only supports 1 to 1 mapping of database tables, views, sprocs and functions available in Microsoft SQL Server. It's a great API to use for quick data access construction to relatively well designed SQL Server databases. LINQ2SQL was first released with C#‎‎‎ 3.0 and .Net Framework 3.5.
LINQ to Entities (ADO.Net Entity Framework) is an ORM (Object Relational Mapper) API which allows for a broad definition of object domain models and their relationships to many different ADO.Net data providers. As such, you can mix and match a number of different database vendors, application servers or protocols to design an aggregated mash-up of objects which are constructed from a variety of tables, sources, services, etc. ADO.Net Framework was released with the .Net Framework 3.5 SP1.

http://stackoverflow.com/questions/8676/entity-framework-vs-linq-to-sql

واین هم نظر یکی از معماران مایکروسافت

LINQ to SQL and the Entity Framework have a lot in common, but each have features targeting different scenarios in the Orcas timeframe.

LINQ to SQL has features targeting "Rapid Development" against a Microsoft SQL Server database. Think of LINQ to SQL as allowing you to have a strongly-typed view of your existing database schema. LINQ to SQL supports a direct, 1:1 mapping of your existing database schema to classes; a single table can be mapped to a single inheritance hierarchy (i.e., a table can contain persons, customers, and employees) and foreign keys can be exposed as strongly-typed relationships. You can build LINQ queries over tables/views/table valued functions and return results as strongly typed objects, and call stored procedures that return strongly typed results through strongly typed methods. A key design principle of LINQ to SQL is that it "just work" for the common cases; so, for example, if you access a collection of orders through the Orders property of a customer, and that customer's orders have not previously been retrieved, LINQ to SQL will automatically get them for you. LINQ to SQL relies on convention, for example default insert, update, and delete logic through generated DML can be overwritten by exposing appropriately named methods (for example, "InsertCustomer", "UpdateCustomer", "DeleteCustomer"). These methods may invoke stored procedures or perform other logic in order to process changes.

The Entity Framework has features targeting "Enterprise Scenarios". In an enterprise, the database is typically controlled by a DBA, the schema is generally optimized for storage considerations (performance, consistency, partitioning) rather than exposing a good application model, and may change over time as usage data and usage patterns evolve. With this in mind, the Entity Framework is designed around exposing an application-oriented data model that is loosely coupled, and may differ significantly, from your existing database schema. For example, you can map a single class (or "entity") to multiple tables/views, or map multiple classes to the same table/view. You can map an inheritance hierarchy to a single table/view (as in LINQ to SQL) or to multiple tables/views (for example, persons, customers, and employees could each be separate tables, where customers and employees contain only the additional columns not present in persons, or repeat the columns from the persons table). You can group properties into complex (or “composite”) types (for example, a Customer type may have an “Address” property that is an Address type with Street, City, Region, Country and Postal code properties). The Entity Framework lets you optionally represent many:many relationships directly, without representing the join table as an entity in your data model, and has a new feature called "Defining Query" that lets you expose any native query against the store as a "table" that can be mapped just as any other table (except that updates must be performed through stored procedures). This flexible mapping, including the option to use stored procedures to process changes, is specified declaratively in order to account for the schema of the database evolving over time without having to recompile the application.

The Entity Framework includes LINQ to Entities which exposes many of the same features as LINQ to SQL over your conceptual application data model; you can build queries in LINQ (or in “Entity SQL”, a canonical version of SQL extended to support concepts like strong typing, polymorphism, relationship navigation and complex types), return results as strongly typed CLR objects, execute stored procedures or table valued functions through strongly-typed methods, and process changes by calling a single save method.

However, the Entity Framework is more than LINQ to Entities; it includes a "storage layer" that lets you use the same conceptual application model through low-level ADO.NET Data Provider interfaces using Entity SQL, and efficiently stream results as possibly hierarchical/polymorphic DataReaders, saving the overhead of materializing objects for read-only scenarios where there is no additional business logic.

The Entity Framework works with Microsoft SQL Server and 3rd party databases through extended ADO.NET Data Providers, providing a common query language against different relational databases through either LINQ to Entities or Entity SQL.

So while there is a lot of overlap, LINQ to SQL is targeted more toward rapidly developing applications against your existing Microsoft SQL Server schema, while the Entity Framework provides object- and storage-layer access to Microsoft SQL Server and 3rd party databases through a loosely coupled, flexible mapping to existing relational schema.

I know this is a confusing area, and we’re trying to figure out how best to describe these differences to help customers make the appropriate choices. Please let me know if this helps, or if there are still areas of confusion…


http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/dc83097e-9c70-4970-93e2-dbc8636eb321


به نظر من EF آمده است تا جنبه ORM فریمورکی مثل LINQ را تکمیل کند نه این که جایگزین آن شود، در واقع شما به جای LINQ To SQL از EF استفاده کنید، نه این که مفهومی به نام LINQ به کلی حذف گردد. LINQ To XXX همچنان در کنار EF پابرجا است.
هر چند دور از انتظار نیست که در آینده هر دو این ابزارها در یک ابزار کارآمد تر و واحد تجمیع شوند.

PLINQO در واقع مدعی است که تکمیل شده و قدرتمند تر از LINQ to SQL است که خوب مشخص است که EF در جهت تکمیل LINQ to SQL معرفی شده است....