Linq-To-Sql Business Layer
翻译对这篇帖子的回复：“由Linq to SQL（L2S）生成的类是业务实体，DAL是L2S生成并内建的‘管道设施’。没有必要将两者分开，只需要在Partial Class中定义业务逻辑就可以了”
那么这里的“ partial Class”指的是什么呢？我提出了一个问题，“
hi KristoferA,
what is "partial classes right there"? for example, if i create a SaleOrders.dbml, do you mean "Partial Class SaleOrdersDataContext" is the partial class? then should I create multiple .dbml file in a class library to implement the business logic?
”
回复是：
Hi Brent,
You wouldn't create a partial class to your DataContext, but rather to your objects. For instance. Let's say you've created a Linq-to-Sql class from a database named "DEV" that contains tables "Table1" and "Table2".
Using the same name space as defined in your DataContext, create a partial class to your objects so when called upon both classes are instantiated as one class. (See : http://msdn.microsoft.com/en-us/library/wa80x488%28VS.80%29.aspx for more information on partial classes)
Since this post, I just create the linq-to-sql class and use it inside my DataAccessLayer. In the end, it's just easier to do for me. IMHO.
-Aaron
我又提了一个问题：
hi KristoferA,
thanks for your response.
I hanve another question. You mentioned that we can just write business logics in the partial classes, then when we have business logic that need to return objects across multiple tables, how to write the code? using the anonymous types or define a Strong Typed object? I think The former method is simple but not suit for large-scale system development, but the latter is hard to implement. Do you have any good suggestions or practices? thanks very much.
Linq-To-Sql Business Layer
Sunday, December 14, 2008 3:48 PM
Hi Everyone,
After hours of reading articles on how to implement business logic into a Linq-to-SQL project, I still can't seem to find a solution that does not require redundant code and that only seems to increase complexity. This discussion has an example of how I would like to implement it with hopes to hear what you, whoever you may be, have to say about it.
Here is a short list of articals and posts I've read through and a lab I studied:
http://msdn.microsoft.com/en-us/library/bb882671.aspx
http://msdn.microsoft.com/en-us/library/bb546176.aspx
http://66.129.67.4/p/1196790/1196790.aspx
http://www.code-magazine.com/Article.aspx?quickid=070153
http://www.c-sharpcorner.com/Forums/ShowMessages.aspx?ThreadID=42585
MSDN Virtual Lab: Using LINQ to SQL with the .Net Framework 3.5 and Visual Studio 2008
The "Idea"
After a long night of dreaming in c#, an idea came to me about using SQLMetal to gerenate the code base from my database. Without the ability to upload version 2,895 of my example of my bussiness logic idea, I'll try to explan what I'm thinking in hopes to hear some pros and cons from you - the professionals.
At this point, my solution idea is made up of two projects. I've not made it to the persentation layer...
Class Library Named : Moline.BusinessEntities
Class Library Named : Moline.DataAccess
Moline.BusinessEntities
I've ran the following command to generate the entities from the database so I can write my bussiness logic from:Once the file is genereated, I moved it to the desired location in my "Moline.BusinessEntities" project and commented out the "DataContext" partial clas so it can NOT to be used to connect to the database. It only contains the objects. I've not seen this done in any articals and to me is seems like an awesome way to gerenrate the code needed to construct the business logic from. Is this a good idea? Or am I really making this harder than I need to?
- SqlMetal.exe /server:.\sqlexpess /database:datastore /namespace:Moline.BusinessEntities /code:c:\Entities.cs
Moving forward, the "Moline.BusinessEntities" project also contains the following classes.5public interface IBaseEntity<TEntity,TPkType>
6 where TEntity : class
7 where TPkType : IComparable
8 {
9 IList<TEntity> Get();
10
11 TEntity Get(TPkType ID);
12
13void Save();
14
15void Save(TEntity entity);
16 }
1public class BaseEntity<TEntity, TPkType, TContext>
2 where TEntity : class, IBaseEntity<TEntity>
3 where TPkType : IComparable
4 where TContext : System.Data.Linq.DataContext
5 {
6
7//This Class Contains all the Business logic for Inserting, Updating, Deleting, ...etc
8internal void SaveBase(TEntity entity, bool hasRelationship) { }
9internal void SaveBase(bool hasRelationship) { }
10public void Delete(TEntity entity, bool hasRelationship) { }
11public void Delete(bool hasRelationship) { }
12 }
Now, I use the classes defined above to construct my objects bussineslogic.
public partial class Person<TEntity, TContext, TPkType>
: BaseEntity<TEntity, TPkType, TContext>, IBaseEntity<TEntity, TPkType>
where TPkType : IComparable
where TEntity : class
where TContext : System.Data.Linq.DataContext
{
#region IBaseEntity<TEntity,TPkType> Members
public new TEntity Get(TPkType ID)
{
return base.Get(ID);
}
public void Save()
{
base.SaveBase(true);
}
public void Save(TEntity entity)
{
base.SaveBase(true, entity);
}
#endregion
}
Moline.DataAccess
Now, I reference my "Moline.BusinessEntities" project in my "Moline.DataAccess" project and from the classes referenced in the Business Logic Layer (BLL) I can create partial classes that uses those two classes - reducing the amount of code and what I think is implementing BLL....public partial class Person
: Person<Person,Data.DataStoreDataContext,Guid>, IBaseEntity<Person, Guid>
{
}
Questions:
Is this the correct way to utilize a BLL with LINQ?
If not, are there any books, articals, ..etc that might help me grasp what I'm missing?
Thanks for taking the time to read through this and I hope it generates some good duscussions around BLL and Linq-to-SQL.
Regards,
Aaron
- Edited byamoline Sunday, December 14, 2008 3:49 PMcorrection
Monday, December 15, 2008 10:05 PM
What, no one wanted to talke about such an exciting topic....or am I that far in left field? =)
Tuesday, December 16, 2008 7:33 AM
KristoferAAnswerer
IMO, the classes generated by L2S are the business entites and the DAL is the "plumbing" generated by and built into L2S. No need to separate the two, instead implement the business logic in partial classes right there.
http://www.huagati.com/dbmltools/ - add new features to the Linq-to-SQL and Entity Framework designersTuesday, December 16, 2008 1:43 PM
KristoferA said:
IMO, the classes generated by L2S are the business entites and the DAL is the "plumbing" generated by and built into L2S. No need to separate the two, instead implement the business logic in partial classes right there.
http://www.huagati.com/dbmltools/ - add new features to the Linq-to-SQL and Entity Framework designersThanks for the response KistoferA. That's how I currently code my data layer. Although I don't change the name space, would you suggest creating a new name space in the project to represent the BLL and the partial classes?
Tuesday, December 16, 2008 1:45 PM
No, a new namespace would mean the partial classes wouldn't become part of the generated classes.
http://www.huagati.com/dbmltools/ - add new features to the Linq-to-SQL and Entity Framework designersWednesday, December 17, 2008 2:41 PM
Duh! I knew that. Thanks again for your input.
