PLINQO - CodeSmith LINQ to SQL Templates

PLINQO, which stands for Professional LINQ to Objects, is a collection of CodeSmith templates that are meant to replace and extend the LINQ to SQL designers that are included with Visual Studio 2008.

Features

  • Generate or update a LINQ to SQL dbml file from a database schema.
    • Includes all tables, stored procedures, functions, and views with the ability to exclude objects based on regex patterns.
    • Ability to automatically remove object prefix and suffixes (ie. tbl_ and usp_).
    • Dbml file can still be customized with the normal Visual Studio 2008 designer.
    • Dbml file can be refreshed based on the current database schema without losing customizations. (See Safe Attributes)
  • Generation of the LINQ to SQL DataContext class.
  • Generation of the LINQ to SQL entity classes.
    • Generates one file per entity instead of one massive file.
    • Generates partial classes where custom code can be written and won't be overwritten.
    • Generated entity files are added to the project as code behind files to their corresponding custom entity files.
  • Generation of entity manager classes.
    • Adds customizable business rules engine to enforce entity validation, business and security rules.
    • Provides access to common queries based on primary keys, foreign keys, and indexes.
    • Common queries are exposed as IQueryable so they can be extended.
  • All templates can be customized to meet your needs.

Read More

http://community.codesmithtools.com/blogs/pwelter/archive/2007/08/08/plinqo.aspx

Download 

http://www.codeplex.com/codesmith/Release/ProjectReleases.aspx 

9 Comments

  • wayde,

    Answers to your points ...

    1) yes, it can be problematic to use the designer. The biggest issue is that as soon as you add a dbml file to a project, Visual Studio set the Custom Tool to MSLinqToSQLGenerator. You need to remove that setting in order for the templates and the designer to work together.

    2) I'd have to agree with you that Wilson syntax is easier. This is the age old debate between manager pattern and active record. The managers are an attempt to have a manager pattern with Linq. The managers are optional however. All you need to get started is the dbml.cst and the entities.cst templates. They will give you the equivalent of the designer.

    I'm also working on a template to have extension methods for the queries. They would extend Table. So you could have the following...

    db.Task.GetById(2);

    That will get you the same syntax as the wilson templates. However, the problem with this is there will be lots of methods off of Table, might be just as confusing/hard to find the query you are looking for?

    To make another point about the managers. The visions of them was to have a common place to put queries. Linq is great for queries, but it also makes it easy to put queries all over the place. I'm trying to have a pattern that will have a central place for them along with other logic for an entity.

    3) I'll look into the issues, thanks for reporting. One note though, i forgot to mention in the post is that you'll need to add a ref to the CodeSmith.Data project that is include for the managers to work.

    4) I just assume nobody used plural names on tables any more. :) I can add that in the next release.

    To answer your other questions ...

    1) No, they are optional.

    2) The managers are just a container for common Linq queries for an entity. They also hold biz logic for the entity. Goal is to create a common place for these things so they don't end up all over the code base. Another nice thing is the template does the hard work of creating compiled queries for indexes and keys.

    3) Yes, sort of. You have to use the special data context for the managers. The entities.cst template creates a SampleDataContext that is the barebones for using linq. The manager.cst template creates a SampleManagerContext that inherits from SampleDataContext to add the manager support. It overrides the SubmitChanges to apply the rules. So as long as you use the SampleManagerContext, the rules will be applied on all SubmitChanges call no matter how you got the data.

    Thanks for you comments and feedback. I hope to grow these templates to make them even more useful. Feedback is greatly appreciated.

    ~ Paul

  • Thanks Paul! That helped to clear things up quite a bit :)

  • Just downloaded the latest version of your templates from codeplex ... getting the following exceptions:

    1. In my DataContext.Generated.cs

    "Error 1 The name 'Properties' does not exist in the current context" Line 44

    2. Also, the problem with the duplicate "using System.Linq" was caused by Partial.cst (it had it duplicated)

    - wayde

  • Another issue:

    Removed the MSLinqToSQLGenerator custom tool, opened up in the designer, modified the name for the Customer entity object (just changed from Customers to Customer), re-generated the code and got several exceptions in just a couple of by stored proc classes.

    Basically within the "Column Mapped Properties" region ... the newly generated code did not include the actual property names.

    e.g. I get

    public Nullable
    {
    get ...

    instead of

    public Nullable ShippedDate
    {
    get

  • wayde,

    Thanks for the bug reports. Guess the designer is removing the Member attribute if its the same as the Name attribute. I'll update to support this.

    I fixed the other issues you've reported.

    thanks again,
    ~ Paul

  • My pleasure.

    You know I was looking over your WilsonORM CS templates and thinking about how your your PLINQO functionality could be retrofitted into producing a bit more intuitive code (as represented by your WORM templates).

    Some ideas. Would they fly?

    1. Implement a singleton pattern for the plinqo DataManagerContext in the same way you did for the worm ObjectSpace in the DataManager.cs

    2. By using the singleton pattern you can add the common 'GetBys' as static methods so that instead of:

    Task t = db.Manager.Task.GetById(1);

    you get:

    Task t = Task.GetById(1);

    Basically, Task.GetById would reference the singleton just as the WORM generated classes.


    Anyways just some ideas. I'm not sure if they represent something possible with linq ... much less a best practice. What do you think?

    - wg

  • I have been using PLinqo extensively over the last few weeks, its great!

    I have uncoverend many bugs and features I have been adding to a thread on the codeplex site. Lets all get serious with it and help Paul really make this what it can be.

    Great job Paul looking for the next TFS build to continue the fixes we have been working on :)

    I now have the code gen'd files in a huge enterprise application, 250+ tables. Its great, lets keep making it better!

  • Hi,

    I made a customization on your template in order to manage the IsDelayLoaded property of fields (which, in my opinion, is one of the most interesting features of LINQ).

    It's very simple, I've added a string property called DelayLoadedPrefix to Dbml.cst template. When a field starts with the value indicated in the property, the field is generated with IsDelayLoaded property as true. If you don't mind I can send the modified template to you.

  • Hi, I'm using PLINQO with ADO.Net Data Services, this works great with the SampleDataContext however I would like to use the manger context (SampleManagerContext) instead to take advantage of the rules, I haven't been able to get SampleManagerContext to work with ADO.Net Data Services, any ideas on how this can be done?

    Paul

Comments have been disabled for this content.