a simple question about design patterns [modified]
-
All -- Please help. I have a simple question about design patterns. I need a quick design-pattern spot-check and thought a guru might have a minute. I am not certain which design-patterns (if any) I am using or if I am using them correctly. The short story... I have a 1-to-1 mapping of DatabaseRow-to-Entity, where each Entity class just holds data. I have a 1-to-1 mapping of EntityManager-to-Entity, where each EntityManager class just handles CRUD operations for its Entity. If handling multiple Entity objects, they are collected into typed collections that are data-bindable. I have a single DataContext that is used only by the EntityManager classes, and the DataContext knows how to connect to the database and run SQL-based CRUD operations I think this uses TableModule + TableDataGateway + RowDataGateway + DataMapper. What do you think? The long story... Here is what I do. For each database table, I have one simple "Entity" class that maps directly to the table row. The Entity exposes each database column as a public property. The only logic in the Entity is validation logic, (such as IncomingValueForProperty1CannotExceedNCharacters, IncomingValueForProperty2CannotBeNull, etc), which simply throws an exception if there is a validation error. There is nothing else in the Entity class-- no SQL, no connection information, no database information, no SaveMethod, no UpdateMethod, nothing, etc. In short, the Entity just holds data. A sample name would be "AddressEntity". Multiple Entity objects are collected in various says, such as a typed-collection, an array of objects, an EntitySet, or similar. For each Entity, I have an "EntityManager" class. The sample name would be "AddressEntityManager". The EntityManager has methods like Create(AddressEntity targetEntity) and Retreive(object ID) and Update(AddressEntity targetEntity) and Delete(object ID). The Manager knows how to get data from the database based on an ID and return the data as a Entity. The Manager knows how to take an Entity passed to it and save the Entity to the database. Etc. The EntityManager uses the DataContext. There is a single "DataContext" class that is used by all EntityManager classes. The DataContext class that knows how to connect to the database and conduct low-level CRUD, SQL-based operations. This is very easy to implement and use. In particular, it is very clear to see who does what in terms of responsibility. The Entity holds data. EntityManager performs CRUD operations on
-
All -- Please help. I have a simple question about design patterns. I need a quick design-pattern spot-check and thought a guru might have a minute. I am not certain which design-patterns (if any) I am using or if I am using them correctly. The short story... I have a 1-to-1 mapping of DatabaseRow-to-Entity, where each Entity class just holds data. I have a 1-to-1 mapping of EntityManager-to-Entity, where each EntityManager class just handles CRUD operations for its Entity. If handling multiple Entity objects, they are collected into typed collections that are data-bindable. I have a single DataContext that is used only by the EntityManager classes, and the DataContext knows how to connect to the database and run SQL-based CRUD operations I think this uses TableModule + TableDataGateway + RowDataGateway + DataMapper. What do you think? The long story... Here is what I do. For each database table, I have one simple "Entity" class that maps directly to the table row. The Entity exposes each database column as a public property. The only logic in the Entity is validation logic, (such as IncomingValueForProperty1CannotExceedNCharacters, IncomingValueForProperty2CannotBeNull, etc), which simply throws an exception if there is a validation error. There is nothing else in the Entity class-- no SQL, no connection information, no database information, no SaveMethod, no UpdateMethod, nothing, etc. In short, the Entity just holds data. A sample name would be "AddressEntity". Multiple Entity objects are collected in various says, such as a typed-collection, an array of objects, an EntitySet, or similar. For each Entity, I have an "EntityManager" class. The sample name would be "AddressEntityManager". The EntityManager has methods like Create(AddressEntity targetEntity) and Retreive(object ID) and Update(AddressEntity targetEntity) and Delete(object ID). The Manager knows how to get data from the database based on an ID and return the data as a Entity. The Manager knows how to take an Entity passed to it and save the Entity to the database. Etc. The EntityManager uses the DataContext. There is a single "DataContext" class that is used by all EntityManager classes. The DataContext class that knows how to connect to the database and conduct low-level CRUD, SQL-based operations. This is very easy to implement and use. In particular, it is very clear to see who does what in terms of responsibility. The Entity holds data. EntityManager performs CRUD operations on
It's an interesting quesiton. First I'd ask, why do you want to know? What value will you receive in mapping patterns to your existing solution? I'm just curious, usually it's the other way around: you have a set of business requirements, then apply various patterns up front during the design process.
Jeremy Likness Latest Article: Whats in Your Collection? Part 1 of 3: Interfaces Blog: C#er : IMage
-
It's an interesting quesiton. First I'd ask, why do you want to know? What value will you receive in mapping patterns to your existing solution? I'm just curious, usually it's the other way around: you have a set of business requirements, then apply various patterns up front during the design process.
Jeremy Likness Latest Article: Whats in Your Collection? Part 1 of 3: Interfaces Blog: C#er : IMage
Jeremy -- Regarding this... >>>why do you want to know? ...I want to know because I want to correct the solution if necessary, and to make the solution better if possible, and to communicate the solution to others using the common terminology, and etc. Regarding this... >>>What value will you receive in mapping patterns to your existing solution? ...the value will be that the solution may be easier to understand, and the solution will be more documented given that it follows a pattern that has already been already well-documented, and the solution will be more fully tested given that it follows a pattern that has already been well-tested, and etc. Thank you. -- Mark Kamoski
-
Jeremy -- Regarding this... >>>why do you want to know? ...I want to know because I want to correct the solution if necessary, and to make the solution better if possible, and to communicate the solution to others using the common terminology, and etc. Regarding this... >>>What value will you receive in mapping patterns to your existing solution? ...the value will be that the solution may be easier to understand, and the solution will be more documented given that it follows a pattern that has already been already well-documented, and the solution will be more fully tested given that it follows a pattern that has already been well-tested, and etc. Thank you. -- Mark Kamoski
Great points! Based on what I read, it sounds like the closest pattern is really Repository. Your "EntityManagers" seem to fit the bill quite nicely.
Jeremy Likness Latest Article: Whats in Your Collection? Part 1 of 3: Interfaces Blog: C#er : IMage
-
All -- Please help. I have a simple question about design patterns. I need a quick design-pattern spot-check and thought a guru might have a minute. I am not certain which design-patterns (if any) I am using or if I am using them correctly. The short story... I have a 1-to-1 mapping of DatabaseRow-to-Entity, where each Entity class just holds data. I have a 1-to-1 mapping of EntityManager-to-Entity, where each EntityManager class just handles CRUD operations for its Entity. If handling multiple Entity objects, they are collected into typed collections that are data-bindable. I have a single DataContext that is used only by the EntityManager classes, and the DataContext knows how to connect to the database and run SQL-based CRUD operations I think this uses TableModule + TableDataGateway + RowDataGateway + DataMapper. What do you think? The long story... Here is what I do. For each database table, I have one simple "Entity" class that maps directly to the table row. The Entity exposes each database column as a public property. The only logic in the Entity is validation logic, (such as IncomingValueForProperty1CannotExceedNCharacters, IncomingValueForProperty2CannotBeNull, etc), which simply throws an exception if there is a validation error. There is nothing else in the Entity class-- no SQL, no connection information, no database information, no SaveMethod, no UpdateMethod, nothing, etc. In short, the Entity just holds data. A sample name would be "AddressEntity". Multiple Entity objects are collected in various says, such as a typed-collection, an array of objects, an EntitySet, or similar. For each Entity, I have an "EntityManager" class. The sample name would be "AddressEntityManager". The EntityManager has methods like Create(AddressEntity targetEntity) and Retreive(object ID) and Update(AddressEntity targetEntity) and Delete(object ID). The Manager knows how to get data from the database based on an ID and return the data as a Entity. The Manager knows how to take an Entity passed to it and save the Entity to the database. Etc. The EntityManager uses the DataContext. There is a single "DataContext" class that is used by all EntityManager classes. The DataContext class that knows how to connect to the database and conduct low-level CRUD, SQL-based operations. This is very easy to implement and use. In particular, it is very clear to see who does what in terms of responsibility. The Entity holds data. EntityManager performs CRUD operations on
As per Fowler, your entity classes will be Data transfer objects[^].
Mark Kamoski wrote:
Multiple Entity objects are collected in various says, such as a typed-collection, an array of objects, an EntitySet, or similar.
Each entity object is a different type. How can you make a single typed collection which are different types? Other than this, your design looks just good. I haven't read Fowlers EAA book and can't comment on the patterns you have provided. But the UML diagrams of those patterns shows, you have got the patterns correctly. :)
Navaneeth How to use google | Ask smart questions
-
As per Fowler, your entity classes will be Data transfer objects[^].
Mark Kamoski wrote:
Multiple Entity objects are collected in various says, such as a typed-collection, an array of objects, an EntitySet, or similar.
Each entity object is a different type. How can you make a single typed collection which are different types? Other than this, your design looks just good. I haven't read Fowlers EAA book and can't comment on the patterns you have provided. But the UML diagrams of those patterns shows, you have got the patterns correctly. :)
Navaneeth How to use google | Ask smart questions
Navaneeth -- Regarding this... >>>Each entity object is a different type. How can you make a single typed collection which are different types? ...that was actually pretty simple. At the implementation level, everything comes back as "IQueryable" and the underlying EntitySet is of the particular type needed. The call-site casts, which is not too much of a burden-- the caller must know what its asking for in a return or must live with a generic IQueryable object. It actually works quite well. Etc. Everything is pretty simple, as follows. This is the interface that is implemented by each EntityManager...
... public interface IL2sEntityManager ... IQueryable Retrieve(); ...This is a sample of what an EntityManager looks like... This is the code being called...... public partial class CategoryCodeManager : Team.Framework.Interfaces.BusinessLayer.BusinessEntities.IL2sEntityManager ... public IQueryable Retrieve() ...This is a sample call-site...... protected void DataBindTest1() { BusinessLayer.BusinessManagers.CategoryCodeManager myManager = new BusinessLayer.BusinessManagers.CategoryCodeManager(); IQueryable myEntitySet = (IQueryable)myManager.Retrieve(); this.EntitySetGridView.DataSource = myEntitySet; this.EntitySetGridView.DataBind(); }Etc. I hope that answers your question. Thank you. -- Mark Kamoski -
All -- Please help. I have a simple question about design patterns. I need a quick design-pattern spot-check and thought a guru might have a minute. I am not certain which design-patterns (if any) I am using or if I am using them correctly. The short story... I have a 1-to-1 mapping of DatabaseRow-to-Entity, where each Entity class just holds data. I have a 1-to-1 mapping of EntityManager-to-Entity, where each EntityManager class just handles CRUD operations for its Entity. If handling multiple Entity objects, they are collected into typed collections that are data-bindable. I have a single DataContext that is used only by the EntityManager classes, and the DataContext knows how to connect to the database and run SQL-based CRUD operations I think this uses TableModule + TableDataGateway + RowDataGateway + DataMapper. What do you think? The long story... Here is what I do. For each database table, I have one simple "Entity" class that maps directly to the table row. The Entity exposes each database column as a public property. The only logic in the Entity is validation logic, (such as IncomingValueForProperty1CannotExceedNCharacters, IncomingValueForProperty2CannotBeNull, etc), which simply throws an exception if there is a validation error. There is nothing else in the Entity class-- no SQL, no connection information, no database information, no SaveMethod, no UpdateMethod, nothing, etc. In short, the Entity just holds data. A sample name would be "AddressEntity". Multiple Entity objects are collected in various says, such as a typed-collection, an array of objects, an EntitySet, or similar. For each Entity, I have an "EntityManager" class. The sample name would be "AddressEntityManager". The EntityManager has methods like Create(AddressEntity targetEntity) and Retreive(object ID) and Update(AddressEntity targetEntity) and Delete(object ID). The Manager knows how to get data from the database based on an ID and return the data as a Entity. The Manager knows how to take an Entity passed to it and save the Entity to the database. Etc. The EntityManager uses the DataContext. There is a single "DataContext" class that is used by all EntityManager classes. The DataContext class that knows how to connect to the database and conduct low-level CRUD, SQL-based operations. This is very easy to implement and use. In particular, it is very clear to see who does what in terms of responsibility. The Entity holds data. EntityManager performs CRUD operations on
All -- If you are interested in a code sample, go to this link... http://linq2sqleb.codeplex.com/SourceControl/PatchList.aspx[^] ...one can and you will file the file "Northwind01_T4Sample_200908141146.zip" is a fully-implemented, working, code sample (with PresentationLayer and BusinessLayer and etc) that shows one way to use T4 ToolBox to generate code from a database, using Linq-To-Sql-Entity-Base, the Repository design pattern (maybe), and a few other goodies. HTH. Thank you. -- Mark Kamoski